Re: [PLUG] Systemd Startup Sequence Question

[Steve Litt <slitt@troubleshooters.com>]

On Mon, 08 May 2017 08:32:12 -0400
Casey Bralla <MailList@nerdworld.org> wrote:

> I've decided I am not a fan of systemd.   

Me neither.

> I was very familiar with
> Debian's sysvinit and Gentoo's OpenRC systems, and could easily
> add/delete services with high reliability.   One thing I loved in
> both systems was the easy way of adding misc programs to be run at
> the end of the boot sequence (/etc/rc.local for Debian
> and /etc/local.d in Gentoo).

The way systemd orders things is by its dependency system. So for a
particular daemon or whatever, you can say it needs to have everything
else loaded first. 

I'm a fan of daemontools-encore. Just make a unit file to run
daemontools-encore late-boot, and add your own daemons to
daemontools-encore. You can also use runit or s6 for that same purpose,
with the advantage that if you ever decide to throw systemd off your
system, runit and/or s6 can be used as actual init systems.

By the way, back when I initted with sysvinit (I use runit today), I
ran daemontools and supervised all my personal daemons with daemontools.

> 
> I have always used these to mount my NFS share drives at the end of
> boot-up.
> 
> Now that I'm running Arch with systemd, things are not so simple.

Just make sure to tell your NFS unit file that it depends on networking
and all mounts.

> AFAIK, Arch has no simple built-in system to run a misc program at
> boot time. However, I loaded an rc.local program from the Arch User
> Repository (AUR), which is supposed to be functionally equivalent to
> the Debian system I'm familar with.
> 
> Except, mounting NFS shares does not work.  I get a "network name not 
> recognized" error at start-up.   

Sounds like it might be part of this new network naming scheme from
Freedesktop.org, where instead of calling your wifi dongle wlan1, it
calls it wl3poetteringsux45transcriptionerror2o5 or something like
that. It's a pain in the ass, but an easily worked around one. See my
get_wifi_dev.sh script

===================================================================
#!/bin/sh
# Copyright (c) 2016 by Steve Litt
# Expat license. See http://directory.fsf.org/wiki/License:Expat

chosen_wifi_number=${1:-1}
wifidevs=0

for dev in `ip -o link | sed -n 's/[^:]*: *\(w[^:]*\).*/\1/p'`;
do
    wifidevs=`expr $wifidevs + 1`
    
    test $wifidevs -eq $chosen_wifi_number && {
        echo $dev
        exit 0
    }
done

echo =max$wifidevs
===================================================================

You could probably call a similar shellscript to get your network
device name, during the boot.

> Once I log in, however, I can
> manually run the rc.local batch file and the shares mount without any
> trouble.
> 
> 
> I presume rc-local is running before the entire entworking system is 
> operational.   Is there a way I can delay the rc.local batch file
> until truly all other systemd processes have started?

That's entirely possible, although it can be avoided with proper
dependencying of the rc.local shellscript's unit file. Also possible is
that some distros, in their infinite wisdom, enable networking in the X
startup, because NetworkManager.

> 
> Anybody got any ideas?

One alternative, as someone else mentioned, is become proficcient with
the creation of unit files. Doing so solves the problems you've
described, but does nothing to solve the April Fools Day architecture
of systemd, systemd's hostility to other software, or systemd's total
repudiation of the concepts of encapsulation and parts
interchangability.

Why have you chosen Arch? Arch is probably the most fanatical
pro-systemd distros: I doubt you'll ever see an Arch setup offered
without systemd.

I use the Void Linux distro with the runit init system. Like systemd,
runit is indeterminate about when things get run. Like systemd, with
runit you can easily express daemon dependency relationships. Unlike
systemd, runit is simple and doesn't require a half dozen
Redhat-salaried programmers to keep it from collapsing under its own
weight.

In runit, you'd make a service directory called "nfs" to run the nfs
daemon. The nfs directory would contain a program called "run", which
looks something like the following:

============================================================
#!/bin/sh
if ping -W 1 -w 1 -c1 nfs_srvr_name.com > /dev/null; then
  exec nfsd
fi
sleep 1
============================================================

Systemd sycophants will hoot and howl at the preceding, singing the
praises of systemd's "declaritive language" over runit's "shellscripts",
but the fact is, with runit's short shellscripts, you can express almost
any conceivable interdaemon relationship.

Your situation is unique to you, so Void Linux might not be your cup of
tea. I'd start by asking yourself what you really want out of Linux,
and evaluate the technology based on that.

SteveT

Steve Litt 
May 2017 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug