获取进程启动时间作为未来日期的方法在Sigar Java API中。

huangapple go评论60阅读模式
英文:

Getting process start time as future date in sigar java api

问题

由于我正在使用sigar java api来获取Solaris Sparc操作系统中进程的启动时间,目前我得到的是未来的启动时间。

有人可以建议可能是什么问题吗?

try {
    startTime = sigar.getProcTime(pid).getStartTime();
} catch (SigarException e) {
}

输出:20230720151134(转换为2023年7月20日)

当我们尝试使用以下命令时

perl -e'@d=localtime ((stat(shift)) [9]) ; printf"%4d%02d%02d----" /proc/34411

我得到了正确的输出。

英文:

As i am using sigar java api to get the process start time in solaris sparc OS,
Currently am getting a future start time as return.

Could anyone suggest what can be the issue?

try {
    startTime = sigar.getProcTime(pid).getStartTime();
} catch (SigarException e) {
}

Output: 20230720151134 (converted july 20 2023)

When we tried with

perl -e'@d=localtime ((stat(shift)) [9]) ; printf"%4d%02d%02d----" /proc/34411

I am getting correct output.

答案1

得分: 2

The authors of SIGAR chose to calculate start time using this calculation:

proctime->start_time = usage.pr_create.tv_sec + sigar->boot_time;
proctime->start_time *= MILLISEC;

This assumes that both the process create time and boot time are accurate. Since you are getting times in the future, this is obviously not the case.

To debug which of those two elements is wrong, you'd need to run code that populates that structure, which reads the contents of /proc/pid/usage into it; it obtains boot_time from KSTAT.

I just queried these values on the GNU Compile Farm Solaris SPARC box (gcc211): The actual process start time from psinfo (and confirmed by matching actual Unix time) was 1685507726287.

I got a boot time of 1652966303 (from kstat -p unix:0:system_misc:boot_time) and create time from usage of 32551759. Adding those times together gives 1685518062000 which is 10335713 milliseconds (2.87 hours) ahead of the actual start time. Further investigation shows the boot time (compared to days+hours+minutes of up time) to be the primary source of that 10336-second difference.

Poking around the internet it appears that boot time is inaccurate in a zone and potentially doesn't reset on a reboot, and other various issues (enter "Solaris boot time inaccurate" in your favorite search engine), so the SIGAR code does appear to be a bug (at least in versions after 8).

I'm not sure why the authors of SIGAR didn't just use the start time from psinfo for this data, and their approach may have worked when they wrote it for an earlier Solaris version. However, the last release was 12 years ago and the last commit to the SIGAR repository was 7 years ago. Any bug won't be fixed. There are alternative actively-maintained Java-based projects to give you information like this, one of which I maintain.

英文:

The authors of SIGAR chose to calculate start time using this calculation:

proctime->start_time = usage.pr_create.tv_sec + sigar->boot_time;
proctime->start_time *= MILLISEC;

This assumes that both the process create time and boot time are accurate. Since you are getting times in the future, this is obviously not the case.

To debug which of those two elements is wrong, you'd need to run code that populates that structure, which reads the contents of /proc/pid/usage into it; it obtains boot_time from KSTAT.

I just queried these values on the GNU Compile Farm Solaris SPARC box (gcc211): The actual process start time from psinfo (and confirmed by matching actual Unix time) was 1685507726287.

I got a boot time of 1652966303 (from kstat -p unix:0:system_misc:boot_time) and create time from usage of 32551759. Adding those times together gives 1685518062000 which is 10335713 milliseconds (2.87 hours) ahead of the actual start time. Further investigation shows the boot time (compared to days+hours+minutes of up time) to be the primary source of that 10336-second difference.

Poking around the internet it appears that boot time is inaccurate in a zone and potentially doesn't reset on a reboot, and other various issues (enter "Solaris boot time inaccurate" in your favorite search engine), so the SIGAR code does appear to be a bug (at least in versions after 8).

I'm not sure why the authors of SIGAR didn't just use the start time from psinfo for this data, and their approach may have worked when they wrote it for an earlier Solaris version. However, the last release was 12 years ago and the last commit to the SIGAR repository was 7 years ago. Any bug won't be fixed. There are alternative actively-maintained Java-based projects to give you information like this, one of which I maintain.

huangapple
  • 本文由 发表于 2023年5月29日 15:56:07
  • 转载请务必保留本文链接:https://go.coder-hub.com/76355576.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定