Re: s6 as a systemd alternative

The s6-svscan and s6-supervise are very simple (and elegant) and in a way do less than runsvdir and runsv: they don't go around allocating resources at runtime. On 30.06.2017 22:38, Steve Litt wrote: On Fri, 30 Jun 2017 19:50:17 + "Laurent Bercot" wrote:

Re: s6 as a systemd alternative

On Fri, 30 Jun 2017 19:50:17 + "Laurent Bercot" wrote: > >The runsv executable is pretty robust, so it's unlikely to die. > Yadda yadda yadda. Most daemons are also unlikely to die, so > following your reasoning, I wonder why we're doing supervision in the >

Re: s6 as a systemd alternative

The runsv executable is pretty robust, so it's unlikely to die. Yadda yadda yadda. Most daemons are also unlikely to die, so following your reasoning, I wonder why we're doing supervision in the first place. Hint: we're doing supervision because we are not content with "unlikely". We want

Re: s6 as a systemd alternative

On Thu, 29 Jun 2017 19:57:55 -0300 Guillermo wrote: > 2017-06-29 1:43 GMT-03:00 Steve Litt: > > > > On Wed, 28 Jun 2017 22:31:12 -0300 Guillermo wrote: > >> > >> But then you end up with an unsupervised runsv process, > >> disconnected from the rest of the supervision

Re: s6 as a systemd alternative

2017-06-29 1:43 GMT-03:00 Steve Litt: > > On Wed, 28 Jun 2017 22:31:12 -0300 Guillermo wrote: >> >> 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

Re: s6 as a systemd alternative

Charles Duffy > - Integration with the linux-only cgroups mechanism for managing CPU, > memory, and I/O throughput limits As you say, this is just an exercise in chain loading tools and conversion to scripts that employ them. * https://news.ycombinator.com/item?id=11846083 *

Re: s6 as a systemd alternative

Casper Ti. Vector: > > (Normally Jonathan would be replying to this point, but I still do not see > him in this thread, so I rashly take this job ;) > Goodonyer. Thank you. I have been distracted. * https://github.com/neovim/neovim/pull/6816 https://github.com/neovim/neovim/pull/6816 I

Re: s6 as a systemd alternative

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

Re: s6 as a systemd alternative

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

Re: s6 as a systemd alternative

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

Re: s6 as a systemd alternative

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

Re: s6 as a systemd alternative

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

Re: s6 as a systemd alternative

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

Re: s6 as a systemd alternative

(Normally Jonathan would be replying to this point, but I still do not see him in this thread, so I rashly take this job ;) On Mon, Jun 26, 2017 at 05:05:15PM +0200, Istvan Szukacs wrote: > I understand that service files are much better that shell scripts Actually they are not. This statement

Re: s6 as a systemd alternative

Would this approach keep systemd installed just to provide for services directly depending on it? # 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

Re: s6 as a systemd alternative

On Mon, Jun 26, 2017 at 04:02:47PM +0200, Istvan Szukacs wrote: > Hi, > > I have a crazy question about s6. Would it be possible to make systemd > compatible? This question might sound stupid at first but here is the > reasoning: > > - we have services with systemd service files already >

Re: s6 as a systemd alternative

Hi Charles, Yeah I can clarify. The only thing that I (or for that matter saner systems engineers) want from systemd is to be a better sysv init. 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

Re: s6 as a systemd alternative

a bunch of hackers behind Void Linux[2] made everything tick on top of runit without all that much effort. 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. See

Re: s6 as a systemd alternative

Could you be more clear about what you mean by "make systemd compatible"? Do you mean loading systemd configuration files into s6, or the reverse? The former strikes me as exceedingly difficult to implement in a complete and correct manner. One of the things that makes systemd so...

Re: s6 as a systemd alternative

Hi Istvan, check out nosh[1]. It explicitly states systemd compat as one of its goals and goes to great lenghts to make it happen. [1]: https://jdebp.eu/Softwares/nosh/ It preserves the daemontools style and spirit. Meanwhile, while hordes of programmers are busy making everything fit into the