Re: Antw: Re: Unexplainable unit restart ("Start request repeated too quickly")

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

   >>> Michael Chapman <mike@xxxxxxxxxxxxxxxxx> schrieb am 03.06.2019 um 11:39
in
Nachricht <alpine.LFD.2.21.1906031935080.3180@xxxxxxxxxx>:
> On Mon, 3 Jun 2019, Ulrich Windl wrote:
> [...]
>> Hi!
>> 
>> The generator unit is:
>> [Unit]
>> Description=I/O performance monitor instance generator
>> Documentation=man:iotwatch‑generator(8) man:iotwatch@.service(8)
>> Wants=nss‑user‑lookup.target time‑sync.target paths.target
>> After=nss‑user‑lookup.target time‑sync.target paths.target
>> ConditionPathExists=/etc/iotwatch.conf
>> Conflicts=shutdown.target
>> 
>> [Service]
>> Type=oneshot
>> ExecStart=/usr/lib/iotwatch/iotwatch‑generator /run/systemd/system
>> TimeoutStartSec=10
>> RestartPreventExitStatus=2 3 4 5
>> StartLimitBurst=1
>> 
>> [Install]
>> WantedBy=default.target iotwatch.target
> 
> 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.

> 
> It's very weird to have what appears to be a generator done as a service 
> though. Any idea why that might be the case?

Yes: systemd generators are called so early that they are not useful in my
case (I cannot have dependencies for the generator). So I have a (little bit
clever) generator service that creates or updates service files "when needed".

> 
>> The iotwatch.target is:
>> [Unit]
>> Description=iotwatch I/O performance monitor
>> Documentation=man:iotwatch@.service(8) man:iotwatch‑generator(8)
>> After=nss‑lookup.target time‑sync.target paths.target
>> Wants=iotwatch@NFS1.service iotwatch@NFS2.service iotwatch@LOC1.service 
>> 
>> [Install]
>> WantedBy=default.target
>> 
>> and the instance services look like:
>> # automatically generated by /usr/lib/iotwatch/iotwatch‑generator
>> 
>> [Unit]
>> Description=iotwatch I/O performance monitor instance "LOC1"
>> Documentation=man:iotwatch(1) man:iotwatch@.service(8)
>> SourcePath=/etc/iotwatch.conf
>> PartOf=iotwatch.target
> 
> That also seems to imply that starting and stopping iotwatch.target would 
> be something that happens with some regularity.

After a configuration change (when the generator actually updated the service
files).


> 
>> Requires=iotwatch‑generator.service
>> Wants=nss‑user‑lookup.target time‑sync.target paths.target
>> After=iotwatch‑generator.service
>> After=nss‑user‑lookup.target time‑sync.target paths.target
>> ConditionPathExists=/etc/passwd
>> Conflicts=shutdown.target
>> 
>> [Service]
>> Type=forking
>> RuntimeDirectory=iotwatch‑LOC1
>> WorkingDirectory=/var/run/iotwatch‑LOC1
>> ExecStartPre=/bin/sh ‑c '...'
>> ExecStart=@/var/run/iotwatch‑LOC1/iotwatch‑LOC1 iotwatch‑LOC1 ‑l ...
>> /etc/passwd
>> ExecStartPost=/usr/bin/sleep 0.2
>> TimeoutStartSec=10
>> ExecStop=/var/run/iotwatch‑LOC1/iotwatch‑LOC1 ‑l ...
>> #SyslogIdentifier=%p‑LOC1
>> TimeoutStopSec=30
>> PIDFile=/var/run/iotwatch‑LOC1/iotwatch‑LOC1.pid
>> Restart=always
>> RestartSec=10s
>> RestartPreventExitStatus=1
>> StartLimitBurst=1
>> 
>> [Install]
>> WantedBy=iotwatch.target
>> 
>> > 
>> > It might also be good to know the RequiredBy, WantedBy, TriggeredBy, 
>> > RequisiteOf and PartOf properties of this iotwatch‑generator.service (see

>> > `systemctl show iotwatch‑generator.service`), since they're possible ways

>> > in which the service may be implicitly started or restarted.
>> 
>> Yes, but I'm missing a log message that explains what happened.
> 
> Sure, there isn't one. That's why I'm asking about the properties.

Thanks for your insights!

Regards,
Ulrich Windl




_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel