[systemd-devel] Problem with intermediate target

Christoph Pleger Christoph.Pleger at cs.tu-dortmund.de
Sat Apr 18 08:39:33 PDT 2015


Hello,

>> 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.

Ah, I understand, that makes it clear. The auto-generated pident.service
file only defines that the service should be executed after
remote-fs.target, but it does not require it, and because no other service
or target wants or requires remote-fs.target before pidentd.service
starts, the filesystems are not yet mounted at that point.

But then, I think that the way how systemd translates LSB init scripts
should be changed. This is the LSB part of /etc/init.d/pidentd:

 ### BEGIN INIT INFO
# Provides:          pidentd-run-dir
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# Default-Start:     S
# Default-Stop:
# Short-Description: setup for pidentd
# Description:       create /var/run/ident for pidentd
### END INIT INFO

As you can see, it defines remote-fs in Required-Start, not in
Should-Start. In my opinion, this should result in an additional
Requires=remote-fs.target in pidentd.service.

Regards
  Christoph



More information about the systemd-devel mailing list