[systemd-devel] systemd-journald, syslog.socket and service activation

[Andrei Borzenkov]

02.07.2020 21:28, Thomas HUMMEL пишет:
> 
> 
> On 02/07/2020 19:00, Andrei Borzenkov wrote:
> 
>> After=syslog.socket will exist only if rsyslog.service is aliased to
>> syslog.service and your problem was when you removed this alias.
> 
> Correct (I did miss this simple thing) !
> 
> 
>> 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.
> 
> 
> hmmm, but since like you said above the After dependency was not taken
> into account as there is no alias, registering failure should not
> prevent rsyslog to be activated (at boot, it end up being dead) ?
> 
>> 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".
> 
> I didn't though indeed about these timing diffrences but, again, without
> the After= having any effect, it should not matter, should it ?
> 
> 
> So I'm still convinces I'm missing something obvious...
> 

It is by far not obvious unfortunately.

Once again - dependencies in systemd are between jobs, not between units.

Rule 1: "B requires A" means "when starting B also submit start job for
A and if this job failed *before we start activating B* cancel
activation of B". If there is already start job for A for other reasons,
the first part does nothing.

Rule 2: "B after A" means "if start job for A is present in job queue
wait for this job to complete before proceeding with start job for B".

In your case on boot you have general Before dependency syslog.socket -
sockets.target - basic.target - rsyslog.service and start request for
both syslog.socket and rsyslog.service are queued. Start job for
rsyslog.service is always delayed at least after basic.target (rule 2).
At this point systemd already tried and failed to start syslog.socket,
so rule 1 applies.