Steve Litt schrob:
> > From a Linux distribution perspective, there's also the question of
> > if s6 can be made a drop-in replacement for daemontools, [...]
>
> In my opinion, 99% of all people currently using daemontools are highly
> technically proficient and could easily either rename commands or
> prepath to a directory containing prefixless symlinked synonyms. IMHO
> if the distro does it, they'll find a way to screw it up. And even if
> the distro does it right, it will screw that 1 in a million people
> (like me) who occasionally use daemontools and s6 on the same box,
> switching between them regularly.
I find these claims to be rather unplausible, given my Debian
experience.
The Debian way would be creating a package "s6-daemontools" containing
just the symlinks from foo to s6-foo and declaring the following package
relationships:
Depends: s6
Conflicts: daemontools
Provides: daemontools
That is, when s6-daemontools is installed:
s6 must also be installed,
daemontools must not be installed,
but daemontools is treated as installed for dependency purposes.
Then, you can choose to install s6 and daemontools together, getting
the default naming for each.
And I can install s6-daemontools and get tai64n/tai64nlocal binaries
that produce correct timestamps despite my kernel clock being set to
UTC. (That is, the ones from s6.)
And every dependency on "daemontools" will be fulfilled, by exactly one
of either djb's daemontools, or s6 plus the symlinks in s6-daemontools.
See espeak-ng-espeak for a real package like that. This is hardly rocket
science, and has been done for *decades* by now.
Maybe non-Debian(-derived) distros are in the business of doing stupid
sh*t, but then you should either switch to a sane distro or be building
your own system. It's certainly no reason to refuse to consider the "s6
as daemontools" concept. Or to insist that people must setup the
symlinks themselves.
Onwards:
Comparing the debian daemontools package with s6 gives:
| $ dpkg -L daemontools | grep /usr/bin/ | sed -E 's_/usr/bin/_/usr/bin/s6-_' | xargs ls -1
| ls: cannot access '/usr/bin/s6-multilog': No such file or directory
| ls: cannot access '/usr/bin/s6-pgrphack': No such file or directory
| ls: cannot access '/usr/bin/s6-readproctitle': No such file or directory
| ls: cannot access '/usr/bin/s6-svscanboot': No such file or directory
| /usr/bin/s6-envdir
| /usr/bin/s6-envuidgid
| /usr/bin/s6-fghack
| /usr/bin/s6-setlock
| /usr/bin/s6-setuidgid
| /usr/bin/s6-softlimit
| /usr/bin/s6-supervise
| /usr/bin/s6-svc
| /usr/bin/s6-svok
| /usr/bin/s6-svscan
| /usr/bin/s6-svstat
| /usr/bin/s6-tai64n
| /usr/bin/s6-tai64nlocal
| $
As Laurent said in the other mail:
> s6-setsid can be symlinked as pgrphack [...]
> s6-log can be symlinked as multilog.
That leaves only readproctitle and svscanboot.
The latter is just clearing env, setting $PATH and executing
svscan /service 2>&1 | readproctitle service errors: .....
with 400 dots, according to the manpage.
But I don't think there's an equivalent of readproctitle in s6.
Plus, there remains the issue of non-compatible supervise directories.
I don't think the above packaging scheme is valid if it would mean
services (with their existing supervise dirs) fail to work because the
supervise(8) implementation got switched from djb to s6 or vice versa.
But in my quick testing they actually could re-use each other's
supervise dir without tripping over the other implementation's
artifacts.¹
Laurent, is that something that should work/you are willing to support?
In that case, readproctitle would be the only remaining obstacle.
regards,
Jan
¹ They would not recognize each other's locking, however.
Received on Sat Dec 21 2019 - 11:49:39 UTC