For complete details, see
https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094
also
https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/
and
https://www.openwall.com/lists/oss-security/2024/03/29/4

Note that Slackware-Current has shipped xz-5.6.1 since it was updated on
2024-03-09. I have no system on which I can test whether the
vulnerability impacts Slackware-current, but I wanted to warn those who
use it. If someone could test and confirm either way whether the
vulnerability is exploitable on Slackware systems (no systemd), I think
that could help plenty of folks.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca
----------------------------------------------------------------------

On 2024-03-29, I wrote:

> Note that Slackware-Current has shipped xz-5.6.1 since it was updated
> on 2024-03-09. I have no system on which I can test whether the
> vulnerability impacts Slackware-current, but I wanted to warn those
> who use it.

Upon further study, I'm led to believe that Slackware is unaffected
(possibly even in Slackware-Current). The malicious code apparently
specifically targets RedHat and Debian derivative build environments,
and at least on my Slackware-15.0 and older systems, liblzma is not
linked into the OS-provided sshd binary.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca
----------------------------------------------------------------------

On Fri, 29 Mar 2024 20:38:32 +0000, Sylvain Robitaille wrote:

> On 2024-03-29, I wrote:
>
>> Note that Slackware-Current has shipped xz-5.6.1 since it was updated
>> on 2024-03-09. I have no system on which I can test whether the
>> vulnerability impacts Slackware-current, but I wanted to warn those who
>> use it.
>
> Upon further study, I'm led to believe that Slackware is unaffected
> (possibly even in Slackware-Current). The malicious code apparently
> specifically targets RedHat and Debian derivative build environments,
> and at least on my Slackware-15.0 and older systems, liblzma is not
> linked into the OS-provided sshd binary.

I'm sure everyones seen Pats Post on the subject that you are referencing
where he already confirmed he does not link in systemd crud that dragsa
in liblzma.

lessons here - always sign your release packages, and with keys held by
you and not your server, always check validity of such d/l'd files...
ummmm... especially when your a distro packager /sigh/

noel <deletethis@invalid.lan> wrote:
> On Fri, 29 Mar 2024 20:38:32 +0000, Sylvain Robitaille wrote:
>
>> On 2024-03-29, I wrote:
>>
>>> Note that Slackware-Current has shipped xz-5.6.1 since it was
>>> updated on 2024-03-09. I have no system on which I can test
>>> whether the vulnerability impacts Slackware-current, but I wanted
>>> to warn those who use it.
>>
>> Upon further study, I'm led to believe that Slackware is unaffected
>> (possibly even in Slackware-Current). The malicious code apparently
>> specifically targets RedHat and Debian derivative build
>> environments, and at least on my Slackware-15.0 and older systems,
>> liblzma is not linked into the OS-provided sshd binary.
>
> I'm sure everyones seen Pats Post on the subject that you are
> referencing where he already confirmed he does not link in systemd
> crud that dragsa in liblzma.
>
> lessons here - always sign your release packages, and with keys held
> by you and not your server, always check validity of such d/l'd
> files... ummmm... especially when your a distro packager /sigh/

And helps not when one of your upstream dependencies has a determined
and patient individual run a multi-year op. to backdoor that
dependency. Which is what the news about the xz backdoor is
indicating. The individual responsible has been slowly working this op
over the course of a few years.

You can sign your release packages, which indicate they came from you.
And you can verify the signatures of your dependences to verify they
came from the dependency author. But if the dependency author starts
running a "backdoor op" on your dependency, you are owned non-the-less.
You verified you were using the proper, official, dependency. It's
just that the proper, official, one is the one that has been
backdoored.

On Sat, 30 Mar 2024 16:50:36 +0000, Rich wrote:
> You can sign your release packages, which indicate they came from you.
> And you can verify the signatures of your dependences to verify they
> came from the dependency author. But if the dependency author starts
> running a "backdoor op" on your dependency, you are owned non-the-less.
> You verified you were using the proper, official, dependency. It's just
> that the proper, official, one is the one that has been backdoored.

Yes, this was even more sneaky. A malicious user has spent a couple of
years to gain the trust to become co-maintainer of project xz. This
malicious user "Jia Tan" could sign his commits and release packages with
GPG keys probably built only for the purpose of a fake "Jia Tan" account.

The sneaky part in this is not that the main developer of xz trusted "Jia
Tan". The sneaky part is not that Linux distributions trusted official
source packages of xz. The sneaky part is that OpenSSH which does not
even itself depend upon xz or liblzma got a backdoor on systemd based
systems.

regards Henrik

Henrik Carlqvist writes:

> Yes, this was even more sneaky. A malicious user has spent a couple of
> years to gain the trust to become co-maintainer of project xz. This
> malicious user "Jia Tan" could sign his commits and release packages with
> GPG keys probably built only for the purpose of a fake "Jia Tan" account.

Someone dug up ample evidence that "Jia Tan" is a composite entity.

Sam <sam@email-scan.com> wrote:
> Henrik Carlqvist writes:
>
>> Yes, this was even more sneaky. A malicious user has spent a couple of
>> years to gain the trust to become co-maintainer of project xz. This
>> malicious user "Jia Tan" could sign his commits and release packages with
>> GPG keys probably built only for the purpose of a fake "Jia Tan" account.
>
> Someone dug up ample evidence that "Jia Tan" is a composite entity.

Given the two year confidence game in building up trust in order to
become a "maintainer" to then insert the very hidden backdoor, "Jia
Tan" looks a lot like an "attacker(s) for hire" and in reality looks
like a state sponsored individual/group operating for pay.

While possible, it seems unlikely that any single individual would be
both a suffiently good "confidence man" to run the two year op to gain
privledge, and also simultaneously be enough of an elete hacker to so
effectively obfscuate the trojan horse deep in the XZ distribution
tarball. The obsfucation level itself is nearly to the level of Ken
Thompson's "Reflections on Trusting Trust" [1]. The fact that having
both in a single individual is unlikely implies a composite "entity" as
the one responsible.

[1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

On 2024-04-01, Henrik Carlqvist wrote:

> The sneaky part in this is not that the main developer of xz trusted
> "Jia Tan". The sneaky part is not that Linux distributions trusted
> official source packages of xz. The sneaky part is that OpenSSH which
> does not even itself depend upon xz or liblzma got a backdoor on
> systemd based systems.

I agree with this, and it makes me feel kind of vindicated in asking
whether or not we really needed a new initd. (I've been asking that
since before systemd came out; I don't recall what the previous initd
proposed replacement was called ... oh yeah, "upstart" on Ubuntu)
Especially one that's apparently trying to replace so many components
of the running operating system. Whatever happened to "do one thing,
and do that one thing well"? sshd on systems without systemd remained
unaffected. That has to be meaningful.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca
----------------------------------------------------------------------

Sylvain Robitaille <syl@therockgarden.ca> wrote:
> ... Whatever happened to "do one thing, and do that one thing
> well"? ...

Consider who is Lennart Poettering's current employer and you will be
able to reason out what happened.

Rich <rich@example.invalid> writes:

> tarball. The obsfucation level itself is nearly to the level of Ken
> Thompson's "Reflections on Trusting Trust" [1]. The fact that having

I didn't fully read and understand the descriptions of the obfuscation,
but I found the use of the m4 file, part of autotools infrastructure I
guess, quite interesting. I also didn't yet find the stamina to read
through a debian devel thread on how they're going to try to improve
verifying archives against source repository contents, but it strikes me
(and I don't want to put this in too simplistic a way - I don't want to
pick on gnu build tooling at all in a "it was the fault of X's ____
software" sort of way) that the way a configure script gets built up,
and how long it ends up being, leaves a lot of dark corners in which to
hide.

I know if I were code reviewing a change that had some understandable C
change in parallel with autoconf build script changes -- the difficulty
I have grasping those tools again causing strain to my limited stamina
-- well, it would be tempting only to concentrate on the C changes.

One of the items that's been popping up in multiple threads concerning
this story is Antonio Diaz Diaz's lzip software and his paper critical
of xz. Bear with me, I'm not intending to go down that road the way you
might think either. I didn't really grasp the paper, but when I glanced
at his source I noticed, IIRC, he'd written his own configure script. It
acted just like a generated autoconf configure script in terms of its
user interface and options, but it wasn't autoconf generated. It strikes
me that for simpler packages that just barely need something like
autoconf but where only a makefile would be insufficient, that this is a
fine approach. Just write the thing yourself for the few things you
need. That would be so much easier to understand as it changes. For more
complex needs, well, use autoconf (or some newer alternative if it's
your thing, but I'd rather people used autoconf in that case rather than
these re-invented wheels -- if you're tired of new init systems you must
be seriously sick of new build systems).

Sylvain Robitaille wrote:

> On 2024-04-01, Henrik Carlqvist wrote:
>
>> The sneaky part in this is not that the main developer of xz trusted
>> "Jia Tan". The sneaky part is not that Linux distributions trusted
>> official source packages of xz. The sneaky part is that OpenSSH which
>> does not even itself depend upon xz or liblzma got a backdoor on
>> systemd based systems.
>
> I agree with this, and it makes me feel kind of vindicated in asking
> whether or not we really needed a new initd. (I've been asking that
> since before systemd came out; I don't recall what the previous initd
> proposed replacement was called ... oh yeah, "upstart" on Ubuntu)
> Especially one that's apparently trying to replace so many components
> of the running operating system. Whatever happened to "do one thing,
> and do that one thing well"? sshd on systems without systemd remained
> unaffected. That has to be meaningful.

I read an article about it a few years ago and I remember thinking, "That
actually sounds like a pretty good idea... that I want absolutely nothing to
do with."

--
The best way to learn is from somebody else's mistakes.
-- Greg Archer, The Valdez Group

On 2024-04-02, Auric__ wrote:

> I read an article about it a few years ago and I remember thinking,
> "That actually sounds like a pretty good idea..."

(purposely trimmed ...)

Oh, that much it is, from an academic standpoint. There are certainly
arguments in favour of it, but not in environments that depend on a
certain stability of the operating system.

I probably read the same article (or certainly one like it) more
than a few years ago, and at the start was thinking "this will be an
interesting read", then afterwards dismayed because I was pretty sure
that it was trying to solve issues that aren't really problems.

There's someone posting to aols from time to time about an initd
replacement that they're working on, and I do find myself interested
in know about it, and that development is progressing, but not at all
in using it. This just strikes me as the sort of thing that folks
should knowingly adopt, on a case-by-case basis, not something that
should be foisted on folks because the operating system packager
(with more bug-for-bug derivatives than true alternatives) decides
that everyone should use it.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca
----------------------------------------------------------------------

Sylvain Robitaille writes:

> There's someone posting to aols from time to time about an initd
> replacement that they're working on, and I do find myself interested

That would be me.

> in know about it, and that development is progressing, but not at all
> in using it.

Well, the future progress would probably be on a steady-but-slow side, since
its functionality is complete, and I can't think of anything more to add
after one more enhancement that I have in the current pipeline. It's just a
container-based pid 1 supervisor. I have little interest in socket
activation, a cron/timer replacement, the whole systemd kitchen sink.

initscripts in Slackware 15 have at least one hidden defect. With
networkmanager enabled with its default dhcpcd configuration: stopping it
manually will leave a daemon process hanging. Shutdown is not clean. This is
gets handled by shutdown/reboot running killall, but will come to light if
someone were to try to shut things down manually (emergency IDS panic comes
to mind).

A container will catch this, and clean it up. This is one argument in favor
of a modern, container-based init replacement.

Sylvain Robitaille wrote:

> On 2024-04-02, Auric__ wrote:
>
>> I read an article about it a few years ago and I remember thinking,
>> "That actually sounds like a pretty good idea..."
>
> (purposely trimmed ...)
>
> Oh, that much it is, from an academic standpoint. There are certainly
> arguments in favour of it, but not in environments that depend on a
> certain stability of the operating system.
>
> I probably read the same article (or certainly one like it) more
> than a few years ago, and at the start was thinking "this will be an
> interesting read", then afterwards dismayed because I was pretty sure
> that it was trying to solve issues that aren't really problems.

My main issue involves the fact that there's essentially a single point of
failure for basically the entire system. See also: the original subject of
this thread.

> There's someone posting to aols from time to time about an initd
> replacement that they're working on, and I do find myself interested
> in know about it, and that development is progressing, but not at all
> in using it. This just strikes me as the sort of thing that folks
> should knowingly adopt, on a case-by-case basis, not something that
> should be foisted on folks because the operating system packager
> (with more bug-for-bug derivatives than true alternatives) decides
> that everyone should use it.

I'll be honest, I'm vaguely interested, but I don't have the inclination to
actually make any changes/customizations to my system. As with lilo (and a
great many other things) what I have now works for me, why bother changing?

--
- You did that on purpose!
- Of course I did. I hate you.

Auric__ writes:

> > in using it. This just strikes me as the sort of thing that folks
> > should knowingly adopt, on a case-by-case basis, not something that
> > should be foisted on folks because the operating system packager
> > (with more bug-for-bug derivatives than true alternatives) decides
> > that everyone should use it.
>
> I'll be honest, I'm vaguely interested, but I don't have the inclination to
> actually make any changes/customizations to my system. As with lilo (and a
> great many other things) what I have now works for me, why bother changing?

If you just want something that works then you're not the target audience,
of course. The target audience would probably be the "because it's there"
crowd. More larger, more better known, distributions have entire communities
on their beta track. That crowd isn't there because they just want something
that works for them.

Or perhaps someone who's building a dedicated system on top of Slackware and
needs something that sysvinit won't provide. And there's always someone for
whom it doesn't work. I already mentioned that I found one stock service
that initscripts don't correctly shut down. I did not check everything in
Slackware. There might be others, and someone dealing with that, but doesn't
want to deal with it.

On 2024-04-03, Sam wrote:

> Well, the future progress would probably be on a steady-but-slow side,
> since its functionality is complete, and I can't think of anything
> more to add after one more enhancement that I have in the current
> pipeline.

.... and that, in my opinion, is ok: it does what it was intended
to do, and assuming you find no major bugs, (and modulo the one
more enhancement) you consider it complete. Time to move on to a
new project. In some circles, it seems that if you cease further
development, your software is suddenly obsolete and undesirable. I
wouldn't agree.

> ... I have little interest in socket activation, a cron/timer
> replacement, the whole systemd kitchen sink.

.... and I thank you for that ... ;-)

> initscripts in Slackware 15 have at least one hidden defect. With
> networkmanager enabled with its default dhcpcd configuration: stopping
> it manually will leave a daemon process hanging.

Hrmmm... interesting. I'll need to look into that on my Slackware-15
systems (though I likely won't have any time to for a few weeks at
least; I'm in the middle of a major relocation). I can see that this
could be missed, though, as for most poeple, networkmanager runs
and stays running until it's time to shut the system down entirely
(or reboot, etc.) Still, there's certainly a fix for that particular
bug that wouldn't involve replacing initd.

> Shutdown is not clean.

Perhaps, but as you point out, it's masked by the call to killall.

> This is gets handled by shutdown/reboot running killall, but will
> come to light if someone were to try to shut things down manually
> (emergency IDS panic comes to mind).

Right ... "/etc/rc.d/rc.networkmanager stop", for example; but would it
*matter*, even then, unless you stopped and started rc.networkmanager
repeatedly?

> A container will catch this, and clean it up. This is one argument in
> favor of a modern, container-based init replacement.

Sure; I don't doubt that there are arguments in favour, but as I noted
in an earlier message, folks should be able to *choose* to install
something like this on a case-by-case basis, with a plain-Jane,
ordinary but reliable initd as the default. Some systems don't make
it an option.

For what it's worth, I probably would argue that you're addressing
the symptom rather than the cause. That said, it's not to dissuade
you, nor to suggest that I can't imagine any use cases for your
"containerized initd", but rather to suggest why I might still prefer
to keep the ordinary initd.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca
----------------------------------------------------------------------

Sylvain Robitaille writes:

> > initscripts in Slackware 15 have at least one hidden defect. With
> > networkmanager enabled with its default dhcpcd configuration: stopping
> > it manually will leave a daemon process hanging.
>
> Hrmmm... interesting. I'll need to look into that on my Slackware-15
> systems (though I likely won't have any time to for a few weeks at
> least; I'm in the middle of a major relocation). I can see that this
> could be missed, though, as for most poeple, networkmanager runs
> and stays running until it's time to shut the system down entirely
> (or reboot, etc.) Still, there's certainly a fix for that particular
> bug that wouldn't involve replacing initd.

Sure: rc.networkmanager needs a fix. But that's the whole point: every
package/service is different. Every package/service will have its own
orderly shutdown process, with its own quirks. Time must be spent figuring
out the right way to stop something.

Why? Just let the container do this for you and don't worry about it.

> > This is gets handled by shutdown/reboot running killall, but will
> > come to light if someone were to try to shut things down manually
> > (emergency IDS panic comes to mind).
>
> Right ... "/etc/rc.d/rc.networkmanager stop", for example; but would it
> *matter*, even then, unless you stopped and started rc.networkmanager
> repeatedly?

I can't say what will be the consequences of a bunch of dhcpcd processes
hanging around, in an unknown state.

But I don't need to worry about it. I solved the problem the easy way (for
an unusual definition of "easy"). This was my pandemic project. It does
sound like somewhat of an overkill, I'll admit to that – writing a whole
pid 1 supervisor just to deal with one runaway process… It's a bit much,
perhaps, just to solve the problem of one zombie process. But I had nothing
better to do, than to solve it …the easy way.

> For what it's worth, I probably would argue that you're addressing
> the symptom rather than the cause. That said, it's not to dissuade
> you, nor to suggest that I can't imagine any use cases for your
> "containerized initd", but rather to suggest why I might still prefer
> to keep the ordinary initd.

Oh, I'd argue the opposite: I am addressing the precise cause. The precise
cause is that software evolved to be too complex, and too complicated to be
effectively managed with simple start and stop scripts. And the solution is
sufficient scaffolding that's capable of supporting and managing complex
software in a way that does not require becoming familiar with its inner
workings.

And let's not forget about elogind, a.k.a. systemd lite.

Slackware took the container-based session manager out of systemd that's
called elogind. I have a hunch that if there was also an easily modularized
container-based pid 1 supervisor that could be taken out of systemd without
everything else that's in the kitchen sink, then this would've happened too.

The same exact reasons why elogind is needed also applies to a pid 1
supervisor.

But, until now, you couldn't have a container-based pid 1 supervisor without
inheriting the rest of systemd.

Well, now you can. Here you go.

And I am shameless enough to assert that this is a better supervisor than
systemd. For starters it uses the new cgroups2 containers, instead of the
original cgroups that systemd uses. Each time a cgroups container stops the
suffering kernel has to start a new process: a separate executable that's
the "release agent" process. This must be done just so it can notify systemd
that this joyous event has happened:

# root@slackware:/sys/fs/cgroup/systemd# cat release_agent
# /lib64/elogind/elogind-cgroups-agent

So, each logout starts elogind-cgroups-agent, just to poke elogind to clean
up the session (it's blissfully unaware otherwise). That's all that this
process does. It starts, it sends a message to elogind that the session
ended, and then it goes away.

This is much simpler with cgroups2: inotify watches cgroup.events in all
containers, and pid 1 gets inotified when one terminates.

My container configuration files are ordinary YAML files, a format that all
new kids on the block understand. It's not like the archaic, Windows-like
structure of systemd's unit configuration files.

systemd's unit files must all live in a designated, flat, directory. That's
so 20th century. Don't you think you have every right to organize your
containers in a meaningful directory hierarchy?

I'll stop now…

On 2024-04-04, Sam wrote:

> Sure: rc.networkmanager needs a fix. But that's the whole point: every
> package/service is different. Every package/service will have its own
> orderly shutdown process, with its own quirks. Time must be spent
> figuring out the right way to stop something.

Correct.

> Why? Just let the container do this for you and don't worry about it.

.... or just let "killall" do it for you ... it (almost) amounts to the
same thing. It's not a fix, but rather masks the problem sufficiently.

> .... I solved the problem the easy way (for an unusual definition of
> "easy").

Well, maybe not so much "easy" as it was "more interesting" to you?

> This was my pandemic project.

There you go. It no doubt served more significant purposes than
"fixing" rc.networkmanager, *but* it also satisfied the approach you
wanted to take towards that problem, because, as you say, other scripts
certainly could also need fixes, and each one would certainly need a
specific fix. That's not a bad thing. It just wouldn't be appropriate
to push it on an OS distribution and force folks to completely relearn
how their systems start up.

>> For what it's worth, I probably would argue that you're addressing
>> the symptom rather than the cause. ....
>
> Oh, I'd argue the opposite: I am addressing the precise cause. The
> precise cause is that software evolved to be too complex, and too
> complicated to be effectively managed with simple start and stop
> scripts.

Well, we're seeing this from different angles. That's ok. I don't
have to convince you and you don't need to convince me.

> And let's not forget about elogind, a.k.a. systemd lite.

"systemd lite" here may be more than a little bit of hyperbole ...
Yes, elogind was extracted (forked) out of the systemd code, but it
was (apparently) done in such a way that includes only that which is
required for the login daemon.

> Slackware took the container-based session manager out of systemd
> that's called elogind.

If you follow the changelog from when that happened, it was needed
for the modern desktop manager(s) that folks want to use. Kudos to
the folks who worked on that for Slackware, for determining exactly
what was needed and changing only those components.

> I have a hunch that if there was also an easily modularized
> container-based pid 1 supervisor that could be taken out of systemd
> without everything else that's in the kitchen sink, then this
> would've happened too.

I have a different hunch: that if a containerized initd was *required*
for some aspect of the OS that was needed to keep Slackware usable
in a modern environment, one would have been found and used (systemd
itself, forked from it, or otherwise).

> The same exact reasons why elogind is needed also applies to a pid 1
> supervisor.

Well, no. Again, see the changelog.

> But, until now, you couldn't have a container-based pid 1 supervisor
> without inheriting the rest of systemd.
>
> Well, now you can. Here you go.

.... and for those that are looking for that, I'm sure they (at least
some?) are grateful.

> And I am shameless enough to assert that this is a better supervisor
> than systemd.

Maybe it is. By your description, it seems that you have managed to
make it be the one thing that you intended it to be, without trying to
replace other parts of the operating system with it.

> My container configuration files are ordinary YAML files, ...

.... "ordinary YAML" may be an oxymoron ... ;-)

> a format that all new kids on the block understand. It's not like the
> archaic, Windows-like structure of systemd's unit configuration
> files.

There's really nothing wrong with key=value simple text files. They're
easily human-readable, and (less easily, I admit) machine parsable.

> systemd's unit files must all live in a designated, flat, directory.

I don't want to be put into a position of trying to defend systemd.
I'm not a fan.

*but* traditional initd files tend to live in a single
directory (/etc/rc.d/ or on some (older?) systems /etc/init.d/
or /etc/rc.d/init.d/ ... I think it may have varied from OS to OS
over the years). There was no particular learning curve. All the
"new kids on the block" could easily understand it as it was.

> That's so 20th century.

.... and this leads me to lose interest in your project. Change for
the sake of change. Maybe stable systems that run reliably and are
easily understood are "so 20th century", but that's what I want out
of my systems.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca
----------------------------------------------------------------------

Sylvain Robitaille <syl@therockgarden.ca> wrote:
> On 2024-04-03, Sam wrote:
>
>> Well, the future progress would probably be on a steady-but-slow side,
>> since its functionality is complete, and I can't think of anything
>> more to add after one more enhancement that I have in the current
>> pipeline.
>
> ... and that, in my opinion, is ok: it does what it was intended
> to do, and assuming you find no major bugs, (and modulo the one
> more enhancement) you consider it complete. Time to move on to a
> new project. In some circles, it seems that if you cease further
> development, your software is suddenly obsolete and undesirable. I
> wouldn't agree.
>
>> ... I have little interest in socket activation, a cron/timer
>> replacement, the whole systemd kitchen sink.
>
> ... and I thank you for that ... ;-)
>
>> initscripts in Slackware 15 have at least one hidden defect. With
>> networkmanager enabled with its default dhcpcd configuration: stopping
>> it manually will leave a daemon process hanging.
>
> Hrmmm... interesting. I'll need to look into that on my Slackware-15
> systems (though I likely won't have any time to for a few weeks at
> least; I'm in the middle of a major relocation). I can see that this
> could be missed, though, as for most poeple, networkmanager runs
> and stays running until it's time to shut the system down entirely
> (or reboot, etc.) Still, there's certainly a fix for that particular
> bug that wouldn't involve replacing initd.
>

2 possible fixes:
1) use NM's internal dhcp client (my solutions).
2) put a script to kill dhcpcd in
'/etc/NetworkManager/dispatcher.d/pre-down.d'

IIRC it also causes exraneous dhcpcd processes when you
sleep/hibernate the system.

>> Shutdown is not clean.
>
> Perhaps, but as you point out, it's masked by the call to killall.
>
>> This is gets handled by shutdown/reboot running killall, but will
>> come to light if someone were to try to shut things down manually
>> (emergency IDS panic comes to mind).
>
> Right ... "/etc/rc.d/rc.networkmanager stop", for example; but would it
> *matter*, even then, unless you stopped and started rc.networkmanager
> repeatedly?
>
>> A container will catch this, and clean it up. This is one argument in
>> favor of a modern, container-based init replacement.
>
> Sure; I don't doubt that there are arguments in favour, but as I noted
> in an earlier message, folks should be able to *choose* to install
> something like this on a case-by-case basis, with a plain-Jane,
> ordinary but reliable initd as the default. Some systems don't make
> it an option.
>
> For what it's worth, I probably would argue that you're addressing
> the symptom rather than the cause. That said, it's not to dissuade
> you, nor to suggest that I can't imagine any use cases for your
> "containerized initd", but rather to suggest why I might still prefer
> to keep the ordinary initd.
>

Sylvain Robitaille writes:

> On 2024-04-04, Sam wrote:
>
> > Why? Just let the container do this for you and don't worry about it.
>
> ... or just let "killall" do it for you ... it (almost) amounts to the
> same thing. It's not a fix, but rather masks the problem sufficiently.

Only if you're shutting down everything.

But it won't help if you want to stop only a single service.

A more realistic example is httpd. I haven't looked at rc.httpd in detail,
but it probably just sigterms every "httpd" process it finds.

I haven't tested this, I don't know if apache goes out of its way to sigterm
any cgi processes that are in flight when it, itself, gets a sigterm. Dunno.

And I don't need to burn time investigating it. I'm running httpd in its own
container. "stop system/rc.M/rc.httpd" will stop Apache and everything that
it started and is still running. Guaranteed.

killall won't help here. Taking Apache down for maintainance is something
that's reasonably expected.

I distinctly recall this being one of the original sales pitches for
systemd: finally you can stop services reliably, and no more headaches with
rogue processes still churning and creating havoc.

> There you go. It no doubt served more significant purposes than
> "fixing" rc.networkmanager, *but* it also satisfied the approach you
> wanted to take towards that problem, because, as you say, other scripts
> certainly could also need fixes, and each one would certainly need a
> specific fix. That's not a bad thing. It just wouldn't be appropriate
> to push it on an OS distribution and force folks to completely relearn
> how their systems start up.

Well, that's what an OS distribution does all the time. ConsoleKit was
replaced with elogind is one example. Also my recollection was that
Slackware used to use /etc/rc[0123456].d/[SK]* scripts for most of its
services. It's now a monolithic rc.M script.

I'm sure there are other examples. You could describe these and other things
as the OS distribution forcing it on others.

> > And I am shameless enough to assert that this is a better supervisor
> > than systemd.
>
> Maybe it is. By your description, it seems that you have managed to
> make it be the one thing that you intended it to be, without trying to
> replace other parts of the operating system with it.

I'm still patting myself on the back, for coming up with this hack. There I
was, sitting back, staring at a generic, but working, pid 1 supervisor. The
initial scaffolding was rudimentary. Since everything got started from rc.M
everything was running in the same container. It works, but it just doesn't
feel right. I was trying to come up with some way to make this better. Then,
the lightbulb moment happened.

I now employ one script to read rc.M (and then, later, rc.inet2), scanning
for occurences of "-x /etc/rc.d/something" followed by, later,
"/etc/rc.d/something start". Plenty of those in there.

A container service gets defined for each one, that runs this in its own
container.

Then, instead of running /etc/rc.d/rc.M in a container, as is, another
script reads /etc/rc.d/rc.M, and replaces every occurence of
"/etc/rc.d/rc.something start", with the container start command. And
instead of running rc.inet2, it runs it through the same wrapper script (not
sure why rc.M is split in two parts, like that, must be some artifact of
history).

rc.M and rc.inet2 are untouched, all of this is done on the fly, and the
result gets executed by the shell. End result: each service in Slackware
gets started in its own container, with all of the initscripts untouched. I
did have to run some interference with rc.local and rc.local_shutdown, due
to the way they're used in rc[06], could not be avoided, but that's the
extent of the mucking. And if rc.M is tweaked further, adding or removing
some stuff, as long as the changes are consisted with the existing style of
coding, in there, everything should work.

The last missing piece is not there yet, but will be soon: silently
implementing the container enable/disable commands, for rc.M service
containers, as a chmod on the underlying rc script. So, now, with a stock
Slackware install:

enable system/rc.M/rc.httpd

translates into flipping the execute bit on rc.httpd. rc.M see this, and
then runs the container start command.

End result: you think you're behind the wheel of a spiffy set of a container
administration service. But you're still running the same initscripts, with
the only difference that each service gets spun up in its own container.

> > My container configuration files are ordinary YAML files, ...
>
> ... "ordinary YAML" may be an oxymoron ... ;-)

Less than "ordinary XML".

> > a format that all new kids on the block understand. It's not like the
> > archaic, Windows-like structure of systemd's unit configuration
> > files.
>
> There's really nothing wrong with key=value simple text files. They're
> easily human-readable, and (less easily, I admit) machine parsable.

If all you need are a flat list of scalar options, perhaps.

But try to add some complexity. Say, one set of options for specifying
possibly multiple "before" dependencies, and another set of options for
specifying possibly multiple "after" dependencies.

Also you need to specify both a starting and a stopping command, and a
possible manual timeout for each one.

You now have logical groups of related options. Sure you can still dump all
of them into a flat "key=value" list. And maybe establish a naming
convention for the "key" part that infers the logical grouping of related
options.

Maybe sprinkle a couple of

[group]

tags, perhaps, in your configuration files. But now you're firmly in the
"hack" territory.

At some point, this crosses the boundary where you want to have some
organized way to define settings. YAML is a natural fit for this.

Let's have a thought experiment. Here's cron's automatically-generated
container, as a YAML configuration file:

name: rc.crond
description: /etc/rc.d/rc.crond
starting:
type: forking
command: /etc/rc.d/rc.crond start
stopping:
type: manual
command: /etc/rc.d/rc.crond stop
before:
- rc.smartd
x-chmod-script: /etc/rc.d/rc.crond
Version: 1

Let's make up a comparable key=value file. Let's say, something like this:

Name=rc.crond
Description=/etc/rc.d/rc.crond
StartType=forking
StartCommand=/etc/rc.d/rc.crond start
StopType=manual
StopCommand=/etc/rc.d/rc.crond stop
StopBefore=rc.smartd
XChmodScript=etc/rc.d/rc.crond
Version=1

The YAML one looks cleaner to me, more expressive, and easier on the eyes.

> > systemd's unit files must all live in a designated, flat, directory.
>
> I don't want to be put into a position of trying to defend systemd.
> I'm not a fan.
>
> *but* traditional initd files tend to live in a single
> directory (/etc/rc.d/ or on some (older?) systems /etc/init.d/
> or /etc/rc.d/init.d/ ... I think it may have varied from OS to OS
> over the years). There was no particular learning curve. All the
> "new kids on the block" could easily understand it as it was.

If you still want to use a single directory, noone will stop you. But, you
might want to keep in mind that all containers that are going to be created
for you, that "come with the system", in a manner of speaking, will be in a
"system" subdirectory, so as long as you stay out of it there won't be any
collision.

> > That's so 20th century.
>
> ... and this leads me to lose interest in your project. Change for
> the sake of change. Maybe stable systems that run reliably and are
> easily understood are "so 20th century", but that's what I want out
> of my systems.

Well, noone's being forced here to do anything. Just because we're now in
the 21st century doesn't mean that the 20th century is forgotten. Sure, you
can still install a pair of links in /etc/rc4.d/S50gizmo and
/etc/rc0.d/K50gizmo. They'll still work as before (but with a helpful
container gets created in system, to keep an eye on them).

Or, you can create your own containers, and organize them in as many
subdirectories as needed, or just in one flat directory, whatever.

Sam <sam@email-scan.com> wrote:
> I distinctly recall this being one of the original sales pitches for
> systemd: finally you can stop services reliably, and no more
> headaches with rogue processes still churning and creating havoc.

One of the earliest 'sales pitches' for systemd was "faster bootups"
with the 'dependency based startup" systemd brought along.

I seem to recall the "clean shutdown of services/daemons" part being
tacked on later when "faster bootups" didn't gain the requisite
traction.

Sam <sam@email-scan.com> wrote:
> Sylvain Robitaille writes:
>
>> On 2024-04-04, Sam wrote:
>> > My container configuration files are ordinary YAML files, ...
>>
>> ... "ordinary YAML" may be an oxymoron ... ;-)
>
> Less than "ordinary XML".
>
>> > a format that all new kids on the block understand. It's not like the
>> > archaic, Windows-like structure of systemd's unit configuration
>> > files.
>>
>> There's really nothing wrong with key=value simple text files. They're
>> easily human-readable, and (less easily, I admit) machine parsable.
>
> If all you need are a flat list of scalar options, perhaps.
>
> But try to add some complexity. Say, one set of options for specifying
> possibly multiple "before" dependencies, and another set of options for
> specifying possibly multiple "after" dependencies.
> ...

> Let's have a thought experiment. Here's cron's automatically-generated
> container, as a YAML configuration file:
>
> name: rc.crond
> description: /etc/rc.d/rc.crond
> starting:
> type: forking
> command: /etc/rc.d/rc.crond start
> stopping:
> type: manual
> command: /etc/rc.d/rc.crond stop
> before:
> - rc.smartd
> x-chmod-script: /etc/rc.d/rc.crond
> Version: 1
>
> Let's make up a comparable key=value file. Let's say, something like this:
>
> Name=rc.crond
> Description=/etc/rc.d/rc.crond
> StartType=forking
> StartCommand=/etc/rc.d/rc.crond start
> StopType=manual
> StopCommand=/etc/rc.d/rc.crond stop
> StopBefore=rc.smartd
> XChmodScript=etc/rc.d/rc.crond
> Version=1
>
> The YAML one looks cleaner to me, more expressive, and easier on the eyes.

I would have converted your YAML into INI format this way:

name=rc.crond
description=/etc/rc.d/rc.crond
x-chmod-script=/etc/rc.d/rc.crond
Version=1
[starting]
type=forking
command=/etc/rc.d/rc.crond start
[stopping]
type=manual
command=/etc/rc.d/rc.crond stop
[before]
commad=rc.smartd

I only had to make up one key name, for the - under before:, and this
more closely mirrors your yaml as well. The [...] section blocks are
in ini files for a reason, they provide first level grouping of keys and
values.

It might also need a starting [main] (or some other name) to make it
fully valid, I've not tried running it through an ini parser. And, ini
files do officially support comments, so the above can also be
(granted, these are made up here as I'm typing, so they seem rather
'redundant' given the names):

name=rc.crond
description=/etc/rc.d/rc.crond
x-chmod-script=/etc/rc.d/rc.crond
Version=1

; how to start up the this unit

[starting]
type=forking
command=/etc/rc.d/rc.crond start

; how to cleanly shutdown the unit

[stopping]
type=manual
command=/etc/rc.d/rc.crond stop

; units that depend upon this one having been started before
; they can themselves be started

[before]
unit=rc.smartd

Rich writes:

> Sam <sam@email-scan.com> wrote:
> > I distinctly recall this being one of the original sales pitches for
> > systemd: finally you can stop services reliably, and no more
> > headaches with rogue processes still churning and creating havoc.
>
> One of the earliest 'sales pitches' for systemd was "faster bootups"
> with the 'dependency based startup" systemd brought along.

I do recall that too.

> I seem to recall the "clean shutdown of services/daemons" part being
> tacked on later when "faster bootups" didn't gain the requisite
> traction.

Then, I suppose, my identical sales pitch won't gain much traction either.
Especially since the imported initscripts' containers' serial sequencing
gets diligently replicated.

Rich writes:

> It might also need a starting [main] (or some other name) to make it
> fully valid, I've not tried running it through an ini parser. And, ini

There are other practical considerations. Yes, there are a couple of ini
parsing libraries out there. Slackware has one, inih.

But it's parse only.

libyaml can read and create YAML files. That's important, since I need to
autogenerate the configuration files for containers of all the imported
initscripts. I don't write them out myself. I use libyaml to do it, so the
formatting is guaranteed to be correct, and there's no uncertainty that
libyaml won't be able to read it back. The example I gave was written via
libyaml.

Sam <sam@email-scan.com> wrote:
> Rich writes:
>
>> Sam <sam@email-scan.com> wrote:
>> > I distinctly recall this being one of the original sales pitches for
>> > systemd: finally you can stop services reliably, and no more
>> > headaches with rogue processes still churning and creating havoc.
>>
>> One of the earliest 'sales pitches' for systemd was "faster bootups"
>> with the 'dependency based startup" systemd brought along.
>
> I do recall that too.
>
>> I seem to recall the "clean shutdown of services/daemons" part being
>> tacked on later when "faster bootups" didn't gain the requisite
>> traction.
>
> Then, I suppose, my identical sales pitch won't gain much traction either.
> Especially since the imported initscripts' containers' serial sequencing
> gets diligently replicated.

Well, you are not starting with "faster booting" and then pivoting when
it turns out that "faster booting" is not a big enough incentive to
jump to your new system.

But you are also fighting against the huge installed base of current
systemd, and that will be difficult to dislodge (just as classic init
took some time for systemd to dislodge) because for most, if what they
have now works, they don't see a reason to switch.

Now, maybe you have an angle with Slackware, but for that you'd need to
be conversing wth Patrick rather than us.