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

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Mon Jun 3 10:43:12 UTC 2019


>>> 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"?
And if RemainAfterExit is on, can I simply "start" a oneshot service again, or do I need a "restart"?

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


> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 






More information about the systemd-devel mailing list