On Sat, 30 Nov 2019 10:15:27 +0000
"Laurent Bercot" <ska-supervision_at_skarnet.org> wrote:
> I hear you. Unfortunately, I have no control over what Debian does.
> Debian isn't even able to ship a not-broken execline package, so I'm
> at a loss on what to do with them. I'm working on a version of
> execline that
> they *might* accept to package correctly, but it's doubtful as long as
> the people in charge are prejudiced against the "lots of small
> binaries in /bin" approach. :(
Would it be acceptable to you and them to put the binaries in /bin/s6
and then very early in the boot add /bin/s6 to the path? This isn't a
lot different from what djb did with /command, except it's not off the
root, which everyone seems to hate.
[snip]
> >3) s6 executables are somehow worse named than runit's. This may be
> > highly subjective, but I can recall and recognize the runit
> > commands far easier than the s6 ones. Possibly it's the "s6-"
> > prefix getting in the way of my brain pattern matching on visual
> > appearance of glyph sequences.
> > This point is exacerbated by #2 and the number of s6 executables.
> > Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid
> > s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the
> > historical reasons, but still.
>
> This is very interesting. I thought that having a s6- prefix was a
> *good*
> thing, because I valued clarity above everything, and especially above
> terseness.
As a guy who has both daemontools and s6 installed on the same box, I
thank you from the bottom of my heart for:
1) Prepending s6- to each command so they don't clash with djb's
2) Except for the s6-, naming them the same as djb's so I have less to
remember.
[snip]
>
> >4) s6 seems more complex (hello execline!), and I don't (yet?) see
> >any
> > benefit/feature I'd appreciate except minimizing wakeups.
>
> This, on the other hand, is a misconception that really needs to
> disappear. Understanding execline is *not needed* to run s6. s6
> depends on execline in two places (there were more, but I scrapped
> them because nobody used the commands that were involved):
> - at build-time, in s6-ftrig-listen
> - at run-time, in s6-log, for processor invocation
>
> Would entirely removing s6's dependency on execline help clear that
> misunderstanding and help with s6 adoption? This could be made
> possible by:
> - duplicating el_semicolon() functionality in s6-ftrig-listen.c
> (it's not elegant, but clearing the dep may be worth it)
> - adding an alternative '?' processor directive to s6-log, that spawns
> the processor using /bin/sh instead of execlineb. (The '!' directive
> would still be there; processor invocations using '!' would just fail
> if execline is not installed.)
>
> I don't like this, but if "execline" is a scarecrow that keeps people
> away from s6 for no other reason than perception, it's a possibility.
> Savvy users will still install execline for use in run scripts.
I don't think it's necessary to remove the dependency unless ordinary
users would be altering the code of s6-ftrig-listen or s6-log.
A simple change change I think would do it is to change the
documentation to imply that, for the *user*, execlineb is a way to get
just a little extra whatever. Currently, when I read it, I thought I'd
be missing a lot by using /bin/sh.
>
> s6-rc, however, absolutely cannot do without execline, since it uses
> autogenerated execline scripts. But s6-rc is a different beast, that
> requires a lot more involvement than s6 anyway, and that isn't needed
> at all if we're just talking about runit-like functionality.
Does the *user* need to code execline scripts, or is it just
something the program does? If the former, then make a point that one
doesn't need to use execline for s6-rc to be a very powerful startup
system.
If anybody would make an execline tutorial, that would help a lot. For
a guy like me who only does procedural programming (C, C++, Pascal,
Perl, Python, Ruby, Lua, etc), execline is difficult to understand.
SteveT
Steve Litt
November 2019 featured book: Manager's Guide to Technical
Troubleshooting Second edition
http://www.troubleshooters.com/mgr
Received on Mon Dec 02 2019 - 02:47:52 UTC