Can one somehow distinguish if,

  • a) the daemon was started during boot or,
  • b) (re)started by an apt-get install or upgrade?

Can this be distinguished from within the daemon itself?

The use case is here to have script that is run by systemd Type=oneshot only run on boot. Not during apt-get install or upgrades.

2 Answers 2


EDIT: Note that I'm talking only about PID 1 because I can't english and thought that you want to check up on your primary init process. Change that to the unit you're interested in. I'm sure systemd will spit PID out for you somehow. Or if not, ps ax |grep [commandname] will do it. You'll likely need to adjust the time difference between uptime and process elapsed time as well, just add a +3 or whatever to bc line./EDIT

I'm not using systemd so take this with a grain of salt. Init-system agnostic way would be to compare the start time of the process you're interested in and system uptime. You can get those with ps -o etimes [PID]. Traditionally, PID 1 is reserved for init process but I don't know if systemd adheres to it. Check with ps 1 if it's indeed the process you're interested in and adjust if not. You can get system uptime in seconds (among others) with cat /proc/uptime |cut -d "." -f 1. Delimiter for cut is dot since ps drops the decimals as well.

compare them with bc or your favorite way. Commandline example could be: echo $(cut -d "." -f 1 /proc/uptime)"-"$(ps -o etimes [PID] |tail -n 1 |tr -d ' \t')|bc Expected output is 0 if the process is started on boot time. You can check if it matches to your findings. For shell scripts, I'd run it thru if/then tests and accept maybe +-3 seconds as boot time. One second at least. Otherwise you could get occasionally a non-zero answer if their uptimes differ even a small fraction of a second which could lead to hard to debug errors.


By design, systemd will start and restart services by running the same commands, under the same environment, etc. either at boot time or during updates. Thus there is no direct way to know if a service is run at boot or restarted after an update. As an administrator, you can infer this by looking at the unit start time, logs, etc.

However, you can work around this by adding specific logic to your service unit, using for example:


ExecStartPre=touch /run/service-was-started-before

Or you can run the command only at boot time using a systemd timer (see systemd.timer(5)) or good old cron.

  • that surely is incorrect. systemd has a bootlogger that even can paint an .SVG graph of all bootprocesses. if a running process is not in there, someone else must have started it.
    – dotbit
    Dec 10, 2019 at 10:34
  • The question is not about being run with or without systemd but about who and when the unit has been started. In both cases (started at boot or restarted during update) the process will be managed by systemd. Dec 11, 2019 at 11:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .