[systemd-devel] Problem with intermediate target

[Christoph Pleger]

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?

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?

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

Regards
  Christoph