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.
Received on Wed Jun 17 2015 - 23:32:42 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC