0

I have a very simple .service file that runs a Bash script, and is tied to a .timer with an identical name.

I'm debugging the failure of the .timer to activate the .service file, but the immediate issue is that

sudo systemctl start p.service

fails to activate the .service file (meaning, run the Bash script), while

sudo systemctl restart p.service

activates the .service file successfully, running the Bash script, just fine.

The question is, why? I imagine this may relate to the failure of the .timer to activate the .service file but perhaps not.

For completeness:

  • The Bash script runs independently specifying the full path to it.
  • The timer's OnCalendar= specification passes inspection using systemd-analyze calendar.
  • Permissions are correct (700 for the script, 644 for the units).
Improve this question
2
  • 3
    Welcome on U&L! Posting the full unit files (except for the parts you feel you shouldn't make public, of course) may let other users give you more helpful advice. For instance, units of type "simple" tend not to play nicely with timers and "oneshot" is often used instead.
    – fra-san
    Commented Mar 15, 2021 at 20:21
  • 1
    It would have also led potential answerers to see the RemainAfterExit, which no one could have guessed without seeing the unit file.
    – Jeff Schaller ♦
    Commented Mar 17, 2021 at 15:08

2 Answers 2

Reset to default
4

Check systemctl status p.service. I suspect the service is active (running). If you try to systemctl start p.service, or trigger it from p.timer, the start command will be ignored.

systemctl restart p.service is a little different in that it will stop the service (if running), then start the service. This will affect an active (running) unit.

Improve this answer
1
  • this is true-the service was active, which did prevent its being triggered a second time. I detail the cause, and what I deduced about the service's triggering events and the operation of the two commands, in my answer below. The documentation addresses none of this, at least obviously. Thanks.
    – ebsf
    Commented Mar 16, 2021 at 15:11
0

It turns out that the reason for the behavior is that the .service file contained the line

RemainAfterExit=yes

The documentation for systemd.service states that this directive is "particularly useful" for oneshot-type services. Nevertheless, it does not disclose that, in leaving the .service file active, a systemd.timer file cannot trigger it again.

I realized this by running

sudo systemctl stop p.service

and seeing the script specified in the unit's ExecStart= directive then run, while thereafter running

sudo systemctl start p.service

had no effect.

This illustrates that a systemd.service unit (or at least its [Service] section directive ExecStart=) is triggered by the unit being stopped (or becoming inactive), not started (or becoming active), at least in the case of Type=oneshot.

This also illustrates that if a systemd.service unit is not otherwise kept active (in this case by RemainAfterExit=yes), then

sudo systemctl start p.service

implies starting, then stopping, the unit. In contrast,

sudo systemctl restart p.service

implies stopping, then starting, the unit. In this sense, the two commands are symmetric counterparts of one another. In both cases, stopping the unit triggers it.

Improve this answer
5
  • 1
    I tend to like using Type=oneshot and ExecStart=/bin/true for meta-services which simply exist to trigger several other services at a time. RemainAfterExit= is perfect for that case because systemctl start will start all of the service's Wants= and Requires= and systemctl stop will stop all PartOf= units.
    – Stewart
    Commented Mar 16, 2021 at 16:18
  • ExecStart= isn't triggered by the unit being stopped. ExecStart= is activated during the activating phase when the unit is started. Upon completion of ExecStart=, the unit transitions to inactive or failed. If you try ExecStart=sleep 10, you'll notice the unit in the activating state for 10s, then it'll go straight to inactive.
    – Stewart
    Commented Mar 16, 2021 at 16:21
  • The meta-service hack is interesting. Regarding ExecStart=, I stand corrected. systemctl stop runs the payload when the service is active and a timer's activation of it is pending as a consequence. Stopping the service allows the pending timer activation to run, activating the service and running the payload. Without a pending timer activation, systemctl stop has no effect and systemctl start activates the service and runs the payload, as you describe.
    – ebsf
    Commented Mar 16, 2021 at 23:09
  • I'm not sure about this part of your answer: "sudo systemctl start p.service implies starting, then stopping, the unit." -- why do you think that systemd would stop the unit when calling start?
    – Jeff Schaller ♦
    Commented Mar 17, 2021 at 15:09
  • Simply because the unit reverts to being inactive after start activates it and it runs, again unless the unit is otherwise kept active after running.
    – ebsf
    Commented Mar 18, 2021 at 17:51

You must log in to answer this question.

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