Post by Sylvain RobitaillePost by SamWhy? 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.
Post by Sylvain RobitailleThere 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.
Post by Sylvain RobitaillePost by SamAnd 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.
Post by Sylvain RobitaillePost by SamMy container configuration files are ordinary YAML files, ...
... "ordinary YAML" may be an oxymoron ... ;-)
Less than "ordinary XML".
Post by Sylvain RobitaillePost by Sama 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.
Post by Sylvain RobitaillePost by Samsystemd'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.
Post by Sylvain RobitaillePost by SamThat'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.