英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论