[systemd-devel] Problem with intermediate target

[Andrei Borzenkov]

В Thu, 16 Apr 2015 17:10:57 +0200
"Christoph Pleger" <Christoph.Pleger at cs.tu-dortmund.de> пишет:

> Hello,
> 
> I wrote:
> 
> >> Sounds like you want to create intermediate.target, change
> >> default.target to point at it, boot all the way up to
> >> intermediate.target, and at that point isolate or start
> >> multi-user.target.
> 
> > I chose that solution, because from all possible solutions for the
> > desired boot order, it seems to be the one which is closest to my idea.
> 
> After setting intermediate.target as default target and defining a service
> belonging to intermediate.target that switches to graphical.target, I
> discovered the following (which does not happen when graphical.target is
> the default target):
> 
> With the package pidentd installed, which does not bring a .service file,
> but only an init script that wants to create a directory /var/run/identd,
> at boot time some error messages appear on the screen that /var is not
> writable. Obviously, /var is not mounted yet when the script is executed.
> After booting, this is the content
> of/run/systemd/generator.late/pidentd.service:
> 
> # Automatically generated by systemd-sysv-generator
> 
> [Unit]
> SourcePath=/etc/init.d/pidentd
> Description=LSB: setup for pidentd
> DefaultDependencies=no
> Before=sysinit.target
> After=remote-fs.target
> 
> [Service]
> Type=forking
> Restart=no
> TimeoutSec=0
> IgnoreSIGPIPE=no
> KillMode=process
> GuessMainPID=no
> RemainAfterExit=yes
> SysVStartPriority=19
> ExecStart=/etc/init.d/pidentd start
> ExecStop=/etc/init.d/pidentd stop
> 
> Why does systemd start this service before /var is mounted, though the
> service should be executed after remote-fs.target, and remote-fs.target
> comes after local-fs.target?
> 

Because remote-fs.target is not part of initial transaction.

> And why is this different in my intermediate.target than in
> multi-user.target, though intermediate.target defines exactly the same
> requirements, orders and conflicts as multi-user.target?
> 

Because systemd allows to declare extra dependencies that are not
directly part of unit definition. E.g. remote-fs.target has
WantedBy=multi-user.target. It is *not* dependencies listed in unit
configuration of multi-user.target that make it start remote-fs.target.

When initial target is multi-user.target all those "reverse
dependencies" (for lack of better word) are pulled in and are part of
initial transaction. With another unit as initial target they are
skipped.

> More strange, when booting is completed, the directory /var/run/identd
> exists. It seems that the init script is called a second time ...
> 

May be. "systemctl -p WantedBy -p RequiredBy pidentd.service" would
answer it.

And no, I do not think it is systemd feature :)