I'm trying to record the start time of a process kicked off by an @reboot cronjob. I'm using ps -p $$ -o ltime= presently, but I've run into a catch.

My machine (a Raspberry Pi) connects to the network and pulls down an NTP update after cron has started and adjusts the system clock. The time returned by lstart changes after the update (which does make sense, of course).

The problem is now I have two different start times, and it looks to my monitoring as if the process was restarted.

Since the reported start time changes when the NTP update comes down it seems like there's an underlying start-time notion that isn't affected by changes to the system clock (otherwise it would continue saying the process started at the old time). How can I get that underlying start-time from a process?

Excerpt from my system logs:

$ grep -e '@reboot' -e 'Time has been' -C 3 /var/log/syslog
Apr  6 13:17:04 archer triggerhappy[386]: Error opening '/dev/input/event*': No such file or directory
Apr  6 13:17:04 archer kernel: [    6.721869] usbcore: registered new interface driver brcmfmac
Apr  6 13:17:04 archer kernel: [    6.930684] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Dec 15 2015 18:10:45 version (r606571) FWID 01-cc4eda9c
Apr  6 13:17:04 archer cron[381]: (CRON) INFO (Running @reboot jobs)
Apr  6 13:17:04 archer wpa_supplicant[376]: Successfully initialized wpa_supplicant
Apr  6 13:17:04 archer dphys-swapfile[385]: want /var/swap=100MByte, checking existing: keeping it
Apr  6 13:17:04 archer avahi-daemon[387]: Found user 'avahi' (UID 105) and group 'avahi' (GID 110).
Apr  6 13:17:15 archer ntpd_intres[587]: DNS 2.debian.pool.ntp.org ->
Apr  6 13:17:15 archer ntpd_intres[587]: DNS 3.debian.pool.ntp.org ->
Apr  6 13:17:17 archer dhcpcd[403]: wlan0: no IPv6 Routers available
Apr  6 13:53:40 archer systemd[1]: Time has been changed
Apr  6 13:54:00 archer systemd[1]: Starting user-1000.slice.
Apr  6 13:54:00 archer systemd[1]: Created slice user-1000.slice.
Apr  6 13:54:00 archer systemd[1]: Starting User Manager for UID 1000...

Notice the time-shift - before that point lstart would report 13:17:04 but after it reports 13:53:27.


You can ask for the elapsed time in seconds:

ps -p $$ -o etimes=

This will always be accurate and comparable, regardless of what the system thinks the current time is.

You can turn it into an unchanging start value by subtracting it from the current uptime (stored in seconds as the first value in /proc/uptime):

echo $(($(cut -d. -f1 < /proc/uptime) - $(ps -p $$ -o etimes=)))
  • Thanks, this turned out to be exactly what I needed. I tried a number of other options but they all ran into edge cases when the clock updates. Avoiding the system clock entirely is really the way to go. – dimo414 Apr 7 '16 at 5:07
  • Yes, I got caught by that issue too in previous versions of the answer. Anything that involves the "current time" at any point fails; you need some sort of stable elapsed time. – Stephen Kitt Apr 7 '16 at 5:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.