Re: s6 as a systemd alternative

[Steve Litt]

On Wed, 28 Jun 2017 22:31:12 -0300
Guillermo  wrote:

> 2017-06-28 14:40 GMT-03:00 Steve Litt:
> >
> > On Mon, 26 Jun 2017 14:53:50 + "Laurent Bercot" wrote:  
> >>
> >>   The problem with the runit model is that it is pure supervision -
> >> it does not provide service management. You have to run all your
> >> oneshots _before_ you can start longruns.  
> >
> > Not necessarily true. You can easily run longruns early by creating
> > a second service directory and a second link directory. You make the
> > service specific directory, create run script and the supervise
> > directory within it, and symlink like the following:
> >
> > ln -s /etc/sv2/gnumeric /var/svlink/gnumeric
> >
> > Then do the following:
> >
> > runsv /etc/svlink/gnumeric  
> 
> But then you end up with an unsupervised runsv process, disconnected
> from the rest of the supervision tree...

I'm not sure about the unsupervised part of it, but I know if the
executable ends another one is run within a second, and I know that you
can turn the executable on and off with 

sv [up|down] /var/svlink/gnumeric
 
SteveT

Steve Litt 
June 2017 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key

Re: s6 as a systemd alternative

[Guillermo]

Hello,

2017-06-26 12:05 GMT-03:00 Istvan Szukacs:
>
> [...] I do not want
> logging, ntp and all the other crap that got sucked into it. I understand
> that service files are much better that shell scripts and this is a good
> argument but it does not justify the idiocracy that systemd became in the
> recent years. Ideally we could have a service (like s6) that does only that
> keeping the best parts of systemd as well. This would allow me to run
> redhat/centos based systems and use service files without being worried
> that a huge amount of CPU cycles going to a service that sole purpose is to
> keep services up that actually provide the functionality that I need. Does
> this clarify?

I'm partially repeating what others have said, but the way I see it:

You seem to be focused only on systemd unit files. An alternative init
system that understands unit files doesn't work as a drop-in
replacement.

1) systemd, the package, is not 'just' an init system. It is a whole
set of low-level userland components, that happens to include among
them a program intended to run as process 1 (also named 'systemd').
Some of the components can work without systemd (the program) being
process 1, like systemd-udevd, and maybe libsystemd (I don't know for
sure). Others, like systemd-logind, cannot. And software packages may
depend on any of those components. For example, GNOME desktop
components do not actually care about the init system, but do want to
be able to send messages over D-Bus to a server implementing the
logind API (as far as I understand).

2) Package dependencies and binary-based distributions. A lot of
software packages that have a real dependency on systemd (a package
that only provides a unit file does not qualify as having a
dependency), have an optional compile-time one (e.g. './configure
--with-systemd'). But if developers of a GNU/Linux distribution choose
to build the package with the option turned on, it becomes a mandatory
runtime dependency for the user. Maybe the dependency is on a
component that doesn't care who's process 1 and you are lucky, or
maybe not. And if that is done with every package shipped by the
distribution, the result is an entanglement with systemd you can't get
out of. So once a binary-based distribution decides to get married to
systemd, I think it is safe to assume that it is a one-way ticket.

So it might be possible to have GNU/Linux and not systemd, but highly
unlikely (IMO) if we are talking RHEL or CentOS.

> # rpm -q --requires openssh-server | grep systemd | sort -u
> libsystemd.so.0()(64bit)
> libsystemd.so.0(LIBSYSTEMD_209)(64bit)
> systemd-units
>
> I am not sure why any service would depend on these. Is there functionality
> in libsystemd.so.0 that an ssh service actually needs?

If that's the software from www.openssh.org, Gentoo's packaging of it
[1] does not list systemd as a dependency, not even conditionally on a
USE flag. I'm guessing that what is shown here is some indirect
dependency through PAM.

G.

[1] https://packages.gentoo.org/packages/net-misc/openssh

Re: s6 as a systemd alternative

[Guillermo]

2017-06-28 14:40 GMT-03:00 Steve Litt:
>
> On Mon, 26 Jun 2017 14:53:50 + "Laurent Bercot" wrote:
>>
>>   The problem with the runit model is that it is pure supervision -
>> it does not provide service management. You have to run all your
>> oneshots _before_ you can start longruns.
>
> Not necessarily true. You can easily run longruns early by creating a
> second service directory and a second link directory. You make the
> service specific directory, create run script and the supervise
> directory within it, and symlink like the following:
>
> ln -s /etc/sv2/gnumeric /var/svlink/gnumeric
>
> Then do the following:
>
> runsv /etc/svlink/gnumeric

But then you end up with an unsupervised runsv process, disconnected
from the rest of the supervision tree...

However, regarding Void Linux and udevd, as far as I can tell by
having a quick look at their GitHub repository, it is launched
unsupervised from /etc/runit/1 just to populate /dev, but then that
process is stopped using 'udevadm control --exit', and a supervised
one is launched. Probably the best possible solution if constrained by
the runit model...

G.

Re: Problems with Step 4

[Guillermo]

Hi,

2017-06-27 16:51 GMT-03:00 Daniel GSJ:
>
> Once stage 2 is reached, the computer hangs in the same way than when
> executing *agetty* in an active console tty, and doesn't login neither.
>
> My o.s. is build with Linux-from-scratch, and is running SystemV, so it is
> a pretty simple system.
>
> I've tried different possibilities like:
>
> #!/bin/sh
>
> exec setsid /sbin/agetty tty5 linux
>
> or
>
> #!/bin/sh
>
> exec chpst -P /sbin/agetty tty5 linux

'chpst -P' from the runit package and setsid from the util-linux
package do the same thing. And this works on my Gentoo machine (using
a minimal setup with almost nothing else running, for testing
purposes). Of course, I have to press CTRL + Alt + F5 to get a login
prompt, otherwise I just see the kernel's and runit's messages. You do
not provide enough context about your problem, e.g. you do not say
where your /etc/runit/1 comes from (did you write it yourself? did you
copy one from somewhere? official instructions from
www.linuxfromscratch.org only mention sysvinit or systemd, so it is
not from there), how you know the stage 2 is reached, what you see on
the console when everything hangs, ...

/root/scan/getty-tty1:
total 8
-rw-r--r-- 1 root root0 Jun 28 20:11 down
-rwxr-xr-x 1 root root   48 Jun 28 20:03 run
drwx-- 2 root root 4096 Jun 28 20:07 supervise

/root/scan/getty-tty5:
total 8
-rwxr-xr-x 1 root root   48 Jun 28 20:03 run
drwx-- 2 root root 4096 Jun 28 20:09 supervise

/root/scan/getty-tty1/run:
#!/bin/sh
exec chpst -P /sbin/agetty tty1 linux

/root/scan/getty-tty5/run:
#!/bin/sh
exec chpst -P /sbin/agetty tty5 linux

  PID  PPID  PGRP COMMAND
1 0 1 runit
  674 1   674 runsvdir -P /root/scan log: 
  675   674   675  \_ runsv getty-tty1
  676   674   676  \_ runsv getty-tty5
  677   676   677  \_ /bin/login --
  682   677   682  \_ -bash
  685   682   685  \_ ps axf -o pid,ppid,pgrp,args

And after doing 'sv up ./scan/getty-tty1' and CTRL + Alt + F1, I can
log on tty1 too:

  PID  PPID  PGRP COMMAND
1 0 1 runit
  674 1   674 runsvdir -P /root/scan log: 
  675   674   675  \_ runsv getty-tty1
  687   675   687  |   \_ /bin/login --
  693   687   693  |   \_ -bash
  694   693   694  |   \_ ps axf -o pid,ppid,pgrp,args
  676   674   676  \_ runsv getty-tty5
  691   676   691  \_ /sbin/agetty tty5 linux

G.

Re: s6 as a systemd alternative

[Alex Efros]

Hi!

On Wed, Jun 28, 2017 at 01:40:18PM -0400, Steve Litt wrote:
> The truth of the preceding statement depends entirely on your
> priorities. If you prioritize simplicity over software orthodoxy, built
> in process ordering, and a maximally recoverable boot instance, you'll
> prefer runit. That's why I prefer runit.
> 
> Runit sounds like it would have a lot more problems than it really
> does. I've used runit on Void for 2 years and have had no problems I
> could trace to any runit software.

+1

I believe there is a place for both runit and s6, and Steve is right, it's
just a question of personal preference.

I'm using runit with Gentoo with trivial /etc/runit/1 instead of default
Gentoo boot/rc scripts for… not sure how long, I believe ~13 years. I use
it this way both on workstations and servers.

Yeah, I run udevd not supervised. And know what? I never had any issues
because of this. And as Steve said this can be solved, but I'm too lazy to
invent /etv/sv2/ and supervise udevd while it works ok.

Moreover, there are a number of other non-supervised processes on my
workstation: mount.ntfs-3g, polkitd, dbus-launch, dbus-daemon, udisksd…
and also several user/GUI related (ssh-agent, xxkb, xscreensaver, dropbox…) -
up to 30 daemon-like processes in sum. Probably some of them will be
auto-restarted by their client software after crash, but not all of them.
So, udevd is "the only one left" only on servers, workstations have a lot
of other daemons, which are much harder or even impossible to supervise.

To be honest, from time to time I consider switching to s6, but this
require some amount of work while everything already works without issues.
And I do like simplicity of my ~250 lines /etc/runit/1.

-- 
WBR, Alex.

Re: s6 as a systemd alternative

[Luis Ressel]

On Wed, 28 Jun 2017 12:44:28 -0400
Steve Litt  wrote:

> 2) Install s6, but run it strictly as a process supervisor

You'd quickly run into dependency problems this way, though. There's a
reason why we have service managers such as s6-rc and anopa.

s6 is powerful on is own, so by all means, switch to it. But as soon as
you feel the need for oneshots or inter-service dependencies, keep in
mind that you'll probably be better of using s6-rc.

Cheers,
Luis Ressel

Re: s6 as a systemd alternative

[Steve Litt]

On Mon, 26 Jun 2017 18:17:29 +0300
Jean Louis  wrote:

> I am user of s6 for reason of simplicity and to avoid trouble of
> systemd.
> 
> While not being developer, maybe it could be possible to have s6 run
> systemd as a service 

Euuu!

> and systemd to run s6 as a service, 

This actually makes sense. One by one move daemons from the
unfathomable systemd to the completely understandable s6, and leave
your binary logs behind on the moved daemons :-)

SteveT

Steve Litt 
June 2017 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key