:: [DNG] Solving simple problems in am…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Rainer Weikusat
Date:  
À: dng
Sujet: [DNG] Solving simple problems in amazingly complicated ways
- the sole purpose of this text is for the amusement of people who ever
had to find a (preferably simple) solution for a complicated problem -

Problem I had to deal with since yesterday: Some Debian 10 system (use
of systemd mandated) installation I've created was to be captured by a
certain image capturing tool running on Windows. As it turned out to be,
this capturing tool has no support for Linux swap partitions and thus,
tries to capture them by doing a sector-by-sectory copy of random junk
which won't ever be of any use again.

Proposed solution: Turn that into an ext4 filesystem, record the UUID,
run a script at boot to convert it back to a swap partition. This could
have been solved by suitable manipulation of /etc/rcS-symlinks but the
mere thought of something as unsophisticated at that would cause systemd
developers to start spinning until the reach escape velocity, never to
be seen again - and who could possibly want that.

So, "we" have to create a systemd unit file to accomplish this by
defining suitable dependencies. It looks like this:

In a section named [Unit], "we declare"

Requires=local-fs.target

This means local-fs.target ("mount local filesystems") has to be started
before us and we don't want to run if it fails. "We then declare"

After=local-fs.target

which means "we don't want to run until local filesystems have actually
been mounted". Then, "We declare"

Before=basic.target

"basic system initialization" ("ready to start servers") shall not be
considered complete until our task is done. Lastly, "we declare"

DefaultDependencies=no

ie, despite we're a service (as determined by the exension of our file
--- pray tell me where this concept came from?) we do want to run
before basic.target and not after it.

Now, we have to switch sections as [Unit] starts to become
boring. Hence, in [Install], we declare

WantedBy=basic.target

Brazenly, we claim basic system initialization "wants us", hence, we
will be started, but if we fail, system boot will continue.

After this (and some other things) were put into a service file in a
suitable location (/etc/systemd/system), it only takes a

systemctl enable name.service

to make it active on boot (by creating some symlinks, mind
you)

- helpfully, if any directives were misspelled or put into the
wrong section, the systemctl call will log a warning message to syslog
(exclusively) and succeed nevertheless -

and - amazingly - systemd can now figure out the required boot ordering
all on its own.

How very soffissicated.