[systemd-devel] Antw: Re: Antw: Re: Unexplainable unit restart ("Start request repeated too quickly")

[Michael Chapman]

On Mon, 3 Jun 2019, Ulrich Windl wrote:
> >>> Reindl Harald <h.reindl at thelounge.net> schrieb am 03.06.2019 um 12:35 in
> Nachricht <e9c0903d-dbae-b9c6-d202-ebb0d0e7b399 at thelounge.net>:
> 
> > 
> > Am 03.06.19 um 12:30 schrieb Ulrich Windl:
> >>> That looks fine, though it _might_ make sense for it to have 
> >>> RemainAfterExit= turned on. After all, if default.target or 
> >>> iotwatch.target get restarted for any reason, then this unit will be 
> >>> started again.
> >> 
> >> That's a valuable hint: I thought systemd would remember that once started
> >> with success, the service is considered started until stopped manually.
> >> So does RemainAFterExit created a kind of dummy process that just remembers
> >> the state? The manual is not clear when you would need it:
> >> 
> >>        RemainAfterExit=
> >>            Takes a boolean value that specifies whether the service shall be
> >>            considered active even when all its processes exited. Defaults to
> >>            no.
> > 
> > a oneshot service without "RemainAfterExit" is not "active" for good
> > reasons - think about timer activated units or socket activated services
> > which both terminate after the last process exits and are started again
> > at the next event
> 
> But why isn't it on by default for "oneshot"?

I don't know, both RemainAfterExit=yes and RemainAfterExit=no are useful, 
so it's hard to know which should be the default.

Regardless, RemainAfterExit=no _is_ the default. Whether or not that's the 
most useful default is irrelevant: it can't be changed now, since any 
change would not be backwards-compatible.

> And if RemainAfterExit is on, can I simply "start" a oneshot service again, or do I need a "restart"?

You would have to restart it. A "start" operation on an active unit is a 
no-op.

> For fun I read systemd.timer, and here the manual page says:
> 
>        RemainAfterExit=
>            Takes a boolean argument. If true, an elapsed timer will stay
>            loaded, and its state remains queriable. Defaults to yes.
> 
> I almost seems as if the defaulkts are just inverted (wrong in both cases).
>
> Regards,
> Ulrich Windl

The directive was added to timer units significantly after it was added to 
service units. Again, I can see use-cases for both settings. For transient 
timers, for instance, it makes sense to discard them completely when 
they've fired. This would correspond closely with the way at jobs work, 
for instance.