Re: [announce] buildroot-s6 0.2.0

2015-11-12 Thread Alex Suykov
Thu, Nov 12, 2015 at 09:29:37PM +0100, Eric Le Bihan wrote: > Comments welcomed! depends on BR2_TOOLCHAIN_USES_GLIBC || BR2_TOOLCHAIN_USES_MUSL looks really strange, uClibc is typically the least problematic libc. I can definitely build it with a uclibc toolchain, all it needs is -lrt in

s6 hangs at shutdown

2015-11-12 Thread Alex Suykov
Hi, I'm trying to reboot s6-based qemu system [1] and it seems to hang at around s6-rc -ad change stage. Could anyone please point out why it can't proceed to reboot, maybe I'm doing something wrong? The system runs with s6-svscan as pid 1. I log in and initiate reboot with s6-svscanctl -i

Re: [announce] buildroot-s6 0.4.0

2016-01-29 Thread Alex Suykov
Wed, Jan 27, 2016 at 01:16:05PM +0100, Laurent Bercot wrote: > And so, daemon packages need to be separated into "mechanism" (the > daemon itself) and "policy" (the way to start it), with as many > "policy" packages as there are supported service managers. This got me thinking of possible

Re: [Announce] s6.rc: a distribution-friendly init/rc framework

2018-03-23 Thread Alex Suykov
Fri, Mar 23, 2018 at 10:51:57AM +, Laurent Bercot wrote: > Bear in mind that - this is a simplified, but descriptive enough view > of the political landscape of the current Linux ecosystem - distribution > maintainers are *lazy*. They already know systemd, or openrc, or > sysvinit; they

Re: runit SIGPWR support

2020-02-28 Thread Alex Suykov
Fri, Feb 28, 2020 at 07:39:47AM +0100, Jan Braun wrote: > The Linux kernel uses SIGPWR to tell init "there's a power failure > imminent". There's a difference to "please shutdown the system", even if > (current versions of) busybox and openrc choose to shutdown the system > when told about an

Re: The "Unix Philosophy 2020" document

2019-12-29 Thread Alex Suykov
Sat, Dec 28, 2019 at 06:41:56PM +0100, Oliver Schad wrote: > > The reason I think it's mostly useless is because the only use case > > for cgroup supervision is supervising double-forking daemons, which > > is not a very smart thing to do. A much better approach is to get rid > > of

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Alex Suykov
Fri, Dec 27, 2019 at 07:23:09PM +0800, Casper Ti. Vector wrote: > I also wonder if someone on this mailing list is interested in actually > implementing a cgroup-based babysitter as is outlined in the post, > perhaps packaged together with standalone workalikes of the cgroup > chainloaders

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Alex Suykov
Fri, Dec 27, 2019 at 04:29:13PM -0500, Steve Litt wrote: > What is slew? I'd guess this thing: https://gitlab.com/CasperVector/slew

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Alex Suykov
Sat, Dec 28, 2019 at 01:46:08AM -0500, Steve Litt wrote: > * No if any code within the s6 stack must be changed. So much good > software has gone bad trying to incorporate features for only the > purpose of getting new users. It does not require any changes to s6. That's a major point I'd

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Alex Suykov
Sat, Dec 28, 2019 at 01:57:25PM +1100, eric vidal wrote: > Well, for me, cgroups is clearly a lack to s6. Using it for every > process like systemd do have no sense, but in some case it can be > useful to protect e.g an "over-eat" allocation memory by a program > (in particular over a server).