libc的gethostname何时返回主机名而非FQDN？

结合你使用的Ubuntu 22.04和glibc 2.35环境，以下是可能的原因：

1. 程序启动时HOSTNAME环境变量被覆盖 #

glibc的gethostname实现会优先检查环境变量中的HOSTNAME值，如果新程序启动时这个变量被设置为foo，就会直接返回短名。比如启动脚本里显式设置了export HOSTNAME=foo，或者通过HOSTNAME=foo ./new_program的方式启动。

2. 程序缺少CAP_SYS_ADMIN权限 #

部分旧程序可能被赋予了CAP_SYS_ADMIN能力，而新程序没有。glibc在获取主机名时，拥有该权限的程序会尝试从系统配置或DNS解析获取FQDN，无权限时则可能直接读取/etc/hostname中的短名。可以用getcap /path/to/old_program和getcap /path/to/new_program对比权限差异。

3. 系统主机名配置的优先级问题 #

Ubuntu的主机名解析依赖/etc/nsswitch.conf中的hosts配置：

• 如果是默认的hosts: files dns，gethostname会优先读取/etc/hostname的内容（短名foo），而hostname --fqdn是通过/etc/hosts中本机IP对应的条目解析出FQDN。
• 只有当gethostname无法从本地文件获取时，才会尝试DNS解析，但这个逻辑在glibc的实现中并不稳定，不同场景下行为可能有差异。

4. 新程序的编译/链接差异 #

如果新程序使用了静态链接（-static参数），或者链接了非系统默认的libc版本，其gethostname的实现逻辑可能和旧程序不同。用ldd /path/to/new_program检查依赖，确认是否和旧程序一样依赖系统的glibc。

5. 程序启动时网络/DNS未就绪 #

如果新程序在系统网络接口未完全初始化、DNS服务还未就绪时启动，gethostname尝试解析FQDN失败后，会 fallback 到短主机名。而旧程序可能是在网络稳定后启动的，所以能返回FQDN。

验证方法 #

• 打印程序的环境变量：在新程序中添加printf("HOSTNAME: %s\n", getenv("HOSTNAME"));，确认是否被覆盖。
• 用strace跟踪系统调用：strace -e gethostname,openat /path/to/new_program，看程序读取了哪些文件，是否尝试了DNS解析。
• 检查/etc/hostname和/etc/hosts：确认/etc/hostname是foo，而/etc/hosts中存在127.0.1.1 foo.example.com foo这类条目。

内容的提问来源于stack exchange，提问作者QF0