On 6/17/2015 1:47 PM, Colin Booth wrote:
/usr/libexec/getty This is true for at least freebsd and openbsd. I
don't have any net, dragonfly, or any of the derivatives to confirm
but I'd be surprised if they moved their getty location.
Thank you for the info.
This is actually a different name than the existing
agetty/fgetty/mingetty that I have, so I can get away with making a new
definition. Nice. :)
It goes a bit deeper than that. For example, the maintenance burdon
for a project like supervision-scripts goes up exponentially as more
services are added since the maintainer needs to follow every service
that they are providing scripts for on the off chance some options get
deprecated or removed.
With yesterday's mention of the idea of a clearinghouse, the concept
that daemon options need to be versioned has been in the back of my
head. Here is an idea: versioned definitions. A crude example:
/etc/sv/sshd/envdir/DAEMON -> /etc/sv/sshd/envdir/current/DAEMON
/etc/sv/sshd/envdir/DAEMONOPTS -> /etc/sv/sshd/envdir/current/DAEMONOPTS
/etc/sv/sshd/envdir/current-> /etc/sv/sshd/versions/v3
/etc/sv/sshd/envdir/versions/v3/DAEMON
/etc/sv/sshd/envdir/versions/v3/DAEMONOPTS
/etc/sv/sshd/envdir/versions/v2/DAEMON
/etc/sv/sshd/envdir/versions/v2/DAEMONOPTS
Settings are now versioned and encapsulated to their definition; old
definitions can be kept indefinitely, allowing you to support older
"legacy" installs; you can still pull just one definition of
/etc/sv/sshd (and all of the files and directories inside of it) out of
a tarball, put it in place, and everything works; no changes are needed
for any run scripts; and if you happen to be running an older version
(for whatever reason) you can easily switch by changing just the
"current" file. Distro maintainers and packagers will not care that
much, because they'll simply point the ./current symlink at whatever
version their daemon uses and they're off to the races.
Drawbacks? File count goes up. Complexity goes up a smidgeon with the
concept of "current". Storage bloats a bit, it seems like symlinks
require an entire disk block on ext3/ext4. And yes, the problem of
getting timely updates for new options still exists. But it's now a
write-it-one-time thing.
With sysvinit on Debian, the package maintainer for a given service
was the person with the onus of making sure that the packaged init
script was correct, but it's a lot easier to maintain the sshd init
script if you're also handling packaging of that service as well. With
systemd, assuming it wins the linux init wars completely, the .service
file can be shoved farther upstream into the service itself. Yes the
BSD package and port maintainers will need to still handle their own
rc files but the maintenance burdon goes down for the packager because
they no longer need to manage the corresponding .service files.
This begs the question - wouldn't the .service files have the
corresponding daemon flags in them? And if so, wouldn't that also imply
that .service files would have the same level of upkeep and maintenance
as run scripts, i.e. with a major version change the parameters change
as well, requiring a new .service? And wouldn't that also mean that
they aren't as "portable" as they would sound, because the same
versioning problem exists?
My theory about why systemd swept through the linux world so fast is
because it's very attractive to package maintainers since one .service
file will run everywhere (as opposed to there being a Debian sysvinit
script, a Gentoo openrc script, an archlinux rc script, an Ubuntu
upstart script, etc...).
To me service units are/Ash nazg durbatulûk/ but that's a personal
opinion. Those .service files seem fishy to me, when Ted T'so had
problems getting one running.
I don't have any systemd-powered hosts right now, but I'd be highly
surprised if systemd shipped with every .service file that it supported.
I think you are correct.
If we really want to make process supervisors into first-class
citizens of the daemon management world, we need to get package
maintainers excited about run scripts in the same way that they got
excited about .service files. The goal should be to sit down at a
supervised system, install a daemon, and have it work under your
supervisor.
Agreed. But we have a chicken-and-egg problem; they won't start the
process of converting to run scripts until someone shows up to "seed" it
first.
