ferm: suggested systemd unit file

[Felipe Sateler]

Hi,

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

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

>
>     [Unit]
>     Description=ferm firewall configuration
>     DefaultDependencies=no
>     Wants=network-pre.target
>     Before=network-pre.target shutdown.target
>     Conflicts=shutdown.target
>
>     [Service]
>     Type=oneshot
>     RemainAfterExit=yes
>     ExecStart=/usr/sbin/ferm /etc/ferm/ferm.conf
>     ExecReload=/usr/sbin/ferm /etc/ferm/ferm.conf
>     ExecStop=/usr/sbin/ferm -F /etc/ferm/ferm.conf
>
>     [Install]
>     WantedBy=network.target
>
> I know you'd prefer to keep backwards-compatibility with
> CACHE/FAST/OPTIONS in /etc/default/ferm. You could do so by changing
> the unit file to match more closely what is output by 'systemctl cat
> ferm.service' on a system that booted with systemd but does _not_ have
> a ferm.service unit file in place. The values in [Unit] should be taken
> from my example, above, however, or the resulting unit file will not
> fix this bug.
>
> The biggest problem with that approach is that you would also pick up
> the default handling of DISABLED which is annoying and not necessary
> under systemd. Your init script would have to be modified to disregard
> the setting for DISABLED when it's being launched by systemd. The
> proper way to do that in a /bin/sh script is '[ -d /run/systemd/systemd
> ]' as used in /lib/lsb/init-functions.d/40-systemd and documented in
> sd_booted(3).
>
> Or you could just drop DISABLED which is not even necessary under
> sysvinit: 'update-rc.d ferm disable' should work just fine for those
> that don't want to rename the symlink in /etc/rcS.d themselves.

Yes, please do not use the DISABLED flag (and kill it from the init
script as well).

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/

-- 

Saludos,
Felipe Sateler