为何faketime命令会跳过部分代码执行？

这个问题挺棘手的——两台配置一致的RHEL7机器，运行同一个CPP程序却出现截然不同的行为，核心差异出在faketime环境下的popen调用环节。结合你已经排查过的点（编译器、代码版本、近似算法），我整理了几个可能的方向和具体排查步骤：

1. 先给代码加上错误处理，定位popen是否失败 #

你的代码里没有检查popen的返回值，如果其中一台机器上popen调用失败（返回NULL），后续访问jitter指针可能直接导致程序崩溃，自然不会输出reached here。先修改代码添加错误判断：

char ntp[]= "192.168.1.200";
FILE *jitter;
char line[100];
char *start;
char * eol;
char pps[] = "NTPS";

// 添加popen错误检查
jitter = popen("chronyc sources", "r");
if (!jitter) {
    cerr << "popen failed with error: " << strerror(errno) << endl;
    return 1; // 或者做其他错误处理
}

cout<<"reached here"<<endl;
while(fgets(line,sizeof(line),jitter)) {
    // ... 原逻辑 ...
}
pclose(jitter);

重新编译后在问题机器上运行，看是否输出错误信息，这能直接告诉你popen失败的原因（比如权限不足、命令不存在、资源限制等）。

2. 检查faketime版本差异 #

虽然机器硬件配置相同，但faketime的版本可能不一样。有些旧版本的faketime对popen这类进程创建调用的拦截存在bug，导致进程无法正常启动。

在两台机器上分别执行：

faketime --version

对比版本号，如果差异较大，尝试在问题机器上升级到和正常机器相同的faketime版本再测试。

3. 测试faketime环境下chronyc能否直接运行 #

问题可能不是代码的popen调用，而是faketime拦截后chronyc命令无法正常执行。直接在问题机器上运行：

faketime 'last friday 5pm' chronyc sources

如果这条命令无法输出结果（比如卡住、报错），那问题根源在faketime和chronyc的交互上，而非你的CPP代码。这种情况下可以尝试：

• 检查chronyc的权限：确认运行程序的用户能正常执行chronyc（非faketime环境下先测试chronyc sources是否正常）
• 检查chronyc的配置：比如是否需要特定的权限访问NTP服务，faketime是否干扰了它的系统调用

4. 检查SELinux或安全策略的影响 #

RHEL7默认启用SELinux，可能其中一台机器的SELinux策略阻止了faketime加载的进程执行popen调用外部命令。

先查看SELinux状态：

getenforce

如果显示Enforcing，临时关闭SELinux测试：

setenforce 0

然后重新运行你的程序，如果恢复正常，说明是SELinux策略的问题，需要调整策略（比如添加自定义规则允许faketime进程执行chronyc）。

5. 检查环境变量差异 #

即使机器配置相同，用户的shell环境变量可能存在差异，尤其是LD_PRELOAD（faketime依赖这个变量加载时间拦截库）。

在两台机器上分别执行：

env | grep -E "(LD_PRELOAD|PATH)"

对比输出：

• 确认LD_PRELOAD中是否包含faketime的库路径，且没有其他冲突的预加载库
• 确认PATH中chronyc的路径一致，避免faketime环境下找不到命令

额外提示：代码中的语法错误 #

注意到你提供的代码里有个明显的语法错误：

start = strpbrk(line,"#0+-";

这里缺少了右引号和右括号，正确写法应该是：

start = strpbrk(line,"#0+-");

虽然你说另一台机器能正常运行，可能是粘贴时的笔误，但还是建议修正，避免后续编译或运行出现未知问题。

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