ferm: suggested systemd unit file

[Felipe Sateler]

On 20 October 2015 at 13:00, Sam Morris <sam at robots.org.uk> wrote:
> On Tue, 2015-10-20 at 12:34 -0300, Felipe Sateler wrote:
>> On 20 October 2015 at 10:23, Sam Morris <sam at robots.org.uk> wrote:
>> > I just ran into this: Ferm was not started at boot. Running
>> > 'journalctl
>> > -b' revealed the following:
>> >
>> >     Oct 20 13:18:37 traxus systemd[1]: Found ordering cycle on basic.target/start
>> >     Oct 20 13:18:37 traxus systemd[1]: Found dependency on sysinit.target/start
>> >     Oct 20 13:18:37 traxus systemd[1]: Found dependency on ferm.service/start
>> >     Oct 20 13:18:37 traxus systemd[1]: Found dependency on network-online.target/start
>> >     Oct 20 13:18:37 traxus systemd[1]: Found dependency on network.target/start
>> >     Oct 20 13:18:37 traxus systemd[1]: Found dependency on systemd-networkd.service/start
>> >     Oct 20 13:18:37 traxus systemd[1]: Found dependency on dbus.service/start
>> >     Oct 20 13:18:37 traxus systemd[1]: Found dependency on basic.target/start
>> >     Oct 20 13:18:37 traxus systemd[1]: Breaking ordering cycle by deleting job ferm.service/start
>> >     Oct 20 13:18:37 traxus systemd[1]: Job ferm.service/start deleted to break ordering cycle starting with basic.target/start
>> >
>> > I am now using the following unit file to start ferm at boot. I use
>> > WantedBy=network.target in the [Install] section because it seems like
>> > a reasonable thing to do, rather than hook into multi-user.target; I
>> > have CCd pkg-systemd-maintainers for a second opinion.
>>
>> No, network.target is a synchronization point, not a place to pull
>> units from. You should instead use multi-user.target if it is required
>> only for normal operation, and sysinit.target if it is required in
>> maintainance mode as well. (Is this part unclear in the wiki page? If
>> so we should clarify this. Suggestions welcome).
>
> I originally skim-read the wiki page and missed the part where it's
> explained that either sysinit.target or multi-user.target should be
> used.

OK. Maybe we should give it a better heading so that it is not so easily missed.

>
>> > The unit also uses {Wants,Before}=network-pre.target as advised in the
>> > Debian wiki page linked for firewall/network type services in the
>> > original bug report.
>>
>> Well, this will depend on each service. In this case, the original
>> init script has Required-Start: $networking which makes it dubious
>> that we want to start ferm before the network is configured. (but I do
>> not use ferm so I don't know for sure).
>
> I'd want firewall rules to be in place before any other process is able
> to start using the network. I think that is the intent of the original
> init script being linked into /etc/rcS.d. Hence network-pre.target
> sounds right to me.

The problem is that at network-pre.target time the interfaces may not
even exist, if the interfaces are not physical (eg, bridges are set up
by networkd or ifupdown, which are After=network-pre.target).

>> I note that upstream ferm already has a service file[1] that does not
>> run at early boot. This suggests that the init script should not run
>> in runlevel S either.
>>
>> [1] http://sources.debian.net/src/ferm/2.2-3/ferm.service/
>
> Yes, I saw this. I decided to try to stay closer to the intent of the
> existing init script. I guess it's up to the (Debian) maintainer which
> gets used. Which, I guess, leaves us with the question of 'should ferm
> be started in maintenence mode'?
>
> AIUI the existing init script would be run if booting into single-user
> mode, so I'd lean towards sysinit.target, not multi-user.target.

I don't have an opinion on who should pull it in. I agree that
consistency is good between init systems, but that can also be
achieved by moving the init script to runlevel 2.

-- 

Saludos,
Felipe Sateler