Re: systemd-journald, syslog.socket and service activation

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

02.07.2020 18:57, Thomas HUMMEL пишет:
> 
> 
> On 02/07/2020 16:44, Andrei Borzenkov wrote:
> 
>> This is common misunderstanding. Dependencies are between jobs, not
>> between units. Requires means systemd will submit additional job for
>> dependent unit - nothing more nothing less. Unless systemd is also told
>> to wait for result of this additional job, both are started in parallel
>> and failure of dependent job does not affect other unit in any way.
> 
> You're right. Sorry if I was not clear.
> Note however that systemd.unit doc talks about units, not jobs for
> Requires=
> 
> Anyway, it turns out that systemctl list-dependencies --after
> rsyslog.service shows also an ordering dependency on sockets.target /
> syslog.socket.
> 
> So, I might be wrong but shouldn't Requires= + After= make the rsyslog
> service fail if syslog.socket fails ?
> 
> # systemctl show -p Requires,After rsyslog.service
> Requires=syslog.socket system.slice sysinit.target
> After=system.slice sysinit.target syslog.socket network.target
> basic.target network-online.target
> 

After=syslog.socket will exist only if rsyslog.service is aliased to
syslog.service and your problem was when you removed this alias.

> Doc says:
> "If this unit gets activated, the units listed will be activated as
> well. If one of the other units fails to activate, and an ordering
> dependency After= on the failing unit is set, this unit will not be
> started. "
> 
> That's what I meant and though it does seems so at boot, I seemed to
> experience the contrary when manually starting rsyslog.service...
> 

On boot activation of syslog.socket happens much earlier than activation
of rsyslog.service which gives systemd enough time to register failure
of syslog.socket. When you start them manually both jobs are submitted
at the same time so activation of rsyslog.service has already happened
when activation of syslog.socket fails. It is already too late for "this
unit will not be started".
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel