On Fri, Aug 21, 2015 at 2:11 AM, Laurent Bercot wrote:
> Wow. Is it a "mount -o remount", or a umount followed by a mount ?
> If a -o remount has this effect on file handles, then it's probably
> worth reporting to the kernel guys, because it's insane.
>
> Even if the script does something nons
On 21/08/2015 07:01, Colin Booth wrote:
Not a bug in s6-rc or s6 but in some Debian script somewhere. Some
single-user script appears to re-mount all mount points, which has the
net result of causing all file handles into tmpfs mounts to go stale.
Wow. Is it a "mount -o remount", or a umount f
On Thu, Aug 20, 2015 at 1:16 PM, Colin Booth wrote:
> By the way, I've found a maybe-bug that, if real, is pretty severe.
> `s6-rc -d change all ; some stuff ; s6-rc -u change all' has caused my
> s6-init + s6-rc testbed system to remove the control pipe for my pid 1
> s6-svscan. I need to make su
On Thu, Aug 20, 2015 at 10:24 AM, Laurent Bercot
wrote:
>
> Oh, the protocol is complicated too. If I start to implement it,
> there's no stopping, and I'll be running behind systemd every time
> they add something to the protocol, which is exactly what I don't
> want to do.
>
Sure. And I bet tha
On 20/08/2015 18:53, Colin Booth wrote:
I think only the socket part is fancy systemd-centric design
Oh, the protocol is complicated too. If I start to implement it,
there's no stopping, and I'll be running behind systemd every time
they add something to the protocol, which is exactly what I d
On Thu, Aug 20, 2015 at 8:44 AM, Laurent Bercot wrote:
> In that case, yes,
> "if { init } if { notification } daemon" is probably the best. It
> represents service readiness almost correctly, if "service" includes
> the initialization.
>
Cool. Not the most elegant but good to know I was on the
On 20/08/2015 16:43, Colin Booth wrote:
Yeah, this is for the special case where you have a daemon that
doesn't do readiness notification but also has a non-trivial amount of
initialization work before it starts. For most things doing the below
talked about oneshot/longrun split is best, but some
On Thu, Aug 20, 2015 at 1:57 AM, Laurent Bercot wrote:
> Just don't have a notification-fd file. s6-rc will assume your daemon
> is ready as soon as the run script is started. It may spam you with a
> warning on high verbosity levels, but that's it. :)
>
Yeah, this is for the special case where y
On Thu, Aug 20, 2015 at 2:35 AM, Laurent Bercot wrote:
>
> I can't grep the word "addition" in my current git, either s6 or s6-rc.
> Are you sure it's not a message you wrote? Can you please give me the
> exact line you're running and the exact output you're getting?
> Thanks,
>
Ugh, it was some
On 20/08/2015 10:57, Laurent Bercot wrote:
s6-svc: warning: /run/s6/rc/scandir/s6rc-fdholder/notification-fdpost
addition of notification-fd
Looks like a missing/wrong string terminator. Thanks for the report,
I'll look for it.
I can't grep the word "addition" in my current git, either s6 o
On 20/08/2015 08:57, Colin Booth wrote:
When running s6-rc -v2 change $bundle, the s6rc-fdholder "pre addition
of notification-fd" message has some garbage characters in it:
s6-svc: warning: /run/s6/rc/scandir/s6rc-fdholderà¯'þpre addition of
notification-fd
s6-svc: warning: /run/s6/rc/scandir/s
Hey all,
I've reconfigured one of my debian systems to boot with s6-init/s6-rc
and while trying to debug a timing issue that I think was my own fault
(my "all services" bundle didn't contain my ersatz single-user
bundle). That mucked up a bunch of timing since half of the
initialization stuff wasn
12 matches
Mail list logo
