Paul Sopka schrob:
> I am not sure if I understand correctly, the files under
> /usr/share/s6-rc/{user,system}
> are to be there only as a reference, not to be edited.
> Are you trying to say that the non-edited files should be symlinked rather
> than copied?
I was indeed trying to say that.
But o
Paul Sopka schrob:
> - The sysadmin or the user can copy a skeleton from
> /etc/s6-rc/skel/{config,src} (which is populated by the package
> manager with configs and initial bundles) to ${HOME}/.config/s6-rc/,
> this folder shall be used for configuration and custom user services.
A skeleton is no
Brett Neumeier schrob:
> 2. patch QEMU to add a signal handler so that it will gracefully
> shutdown when it receives a specific signal (and then tell s6 to use
> that signal to take the service down); or
A patch to do that has been available since 2017 at least, but the qemu
developers apparently
Hey,
I don't want to pick a side in the turnstile-or-not fight, so I
found something you seemed to agree on, to disagree with:
Paul Sopka schrob:
> > [...] and unless you want to make users replace their shell with
> > something like `/etc/execline-startup` as described in
> > https://skarnet.org/
Hey,
Paul Sopka schrob:
> [ user services have service dir in /run and logs in /var ]
> What do you think about that reasoning?
Agree.
Besides consistency, putting those below $HOME would also break in NFS
setups where $HOME is shared among several machines.
> I do not *want* to adhere to the XD
Peter Pentchev schrob:
> On Sat, Jul 06, 2024 at 01:45:42AM +0200, Paul Sopka wrote:
> > System supervision tree logs to to /var/log/${daemon}
> >
> > User supervision tree logs got to /var/log/${USER}/${daemon}
>
> Quick question (that you may have already thought about, apologies in
> advance):
Paul Sopka schrob:
> An alternative would be two main bundles per user service tree, that itself
> always starts on boot:
>
> One to start at boot time.
> Another one to start on first login and stop on last login.
> This seems the most elegant and efficient. Am I overlooking anything?
I am not t
Paul Sopka schrob:
> My claim was more about a practical, applied scenario. In the terms of: If a
> user is not logged in, he simply cannot control his services. So why shall
> he have an entire user supervision tree of which the sole purpose is to
> allow the user to control the services running w
Laurent Bercot schrob:
> IIRC, 1. is intrinsic to runit, there is no way to redirect the default
> logging, [...]
There is: the default logging simply goes to runsvdir's stdout. You can
connect that in /etc/runit/2 to wherever you like.
> a runit service should use the runit logging facility. Tha
John W Higgins schrob:
> I meant nothing towards s6 - but daemontools does not deal with leap
> seconds (or at least it cetainly looks that way from my foolish viewpoint).
Daemontools assumes that time(3) returns TAI-like time (seconds actually
elapsed since the epoch). That's a rather sane approa
Hey,
Carl Winbäck schrob:
> Is it possible when using s6-svscan/s6-supervise to somehow arrange so
> that a daemon’s stdout is sent to one logdir and stderr to another
> logdir?
I'm not completely sure about s6, but runsv (from runit) hands only the
stdout of the ./run script to the logger, and p
innerspacepilot schrob:
> I have checked openrc and busybox - both support SIGPWR.
>
> So I see no reason to change lxd behaviour, unless some realworld
> software uses SIGPWR.
*sigh* We've been here before.
The Linux kernel uses SIGPWR to tell init "there's a power failure
imminent". There's a d
Laurent Bercot schrob:
> No, you're falling for the pretext - because this is only the current
> pretext they're using. Debian *does not provide* a POSIX-compliant cd
> binary, so their claims at POSIX compliance are just lies.
Including execline's (non-compliant) cd would preclude them from
becom
Colin Booth schrob:
> > If you're referring to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
> > then, well, you are fighting against POSIX. There's little choice for
> > Debian in the matter. Taking a hardline stance on such "legal" issues is
> > part of their identity as a distr
Steve Litt schrob:
> > From a Linux distribution perspective, there's also the question of
> > if s6 can be made a drop-in replacement for daemontools, [...]
>
> In my opinion, 99% of all people currently using daemontools are highly
> technically proficient and could easily either rename commands
Hey,
and sorry for taking so long to reply.
Laurent Bercot schrob:
> > 1) Debian ships with a working and maintained runit-init package. It
> >provides pid 1 and hooks into /etc/rcS.d/* to integrate with other
> >Debian packages. s6-linux-init and s6-rc are not packaged in Debian.
>
> I h
Hi,
Laurent Bercot schrob:
> - My opinion is that the most sustainable path forward, for runit
> users who need a centrally maintained supervision software suite, is to
> just switch to s6 - and it comes with several other benefits as well.
As a relatively new convert to supervision software, my
Laurent Bercot schrob:
> I don't think the historical behaviour is a *bug*, because the
> historical behaviour is documented and conforms to its documentation.
Well, let's say "misfeature" ;)
> It also comes from a time when supplementary groups weren't used as
> much as they are today.
>
> It
Cameron Nemo schrob:
> Most of these (su, sudo, runuser) go through PAM.
> su and sudo are primarily targeted at interactive use.
As a shell junkie, I don't subscribe to the viewpoint that there's a
measurable difference between "interactive use" and "scripting". ;)
> > So now I'm wondering:
> >
Jonathan de Boyne Pollard schrob:
> > My inability to see the issue came from the fact that all other similar
> > programs (I'm aware of) do in fact add the supplementary groups.
> >
> Then you are not aware of Bernstein daemontools, where setuidgid does not.
> (-:
Well, I am aware of their exist
Hello list!
Yesterday, I spent way too much time chasing down a permissions problem
caused by the fact that "chpst -u acc prog..." only sets the account's
primary group, and ignores any supplementary groups the account may be a
member of.
TFM mentions "All initial supplementary groups are removed
Patrick Steinhardt schrob:
> Yeah, I thought about using a symlink here, too. The main reason
> why I didn't want to do this is to keep configuration and data
> separate from each other. It honestly feels a bit weird to me to
> configure the logger in /var/log/$service -- doing so in
> /etc/sv/$ser
22 matches
Mail list logo
