[2018-12-27 15:52] Lorenz
>
> part 2 text/plain 533
> On Thu, 20 Dec 2018 18:04:25 + Dmitry Bogatov
> wrote:
> > ... What do you think about state of
> > salsa:runit-team/runit, commit a8d698d? I am considering uploading it to
> > unstable.
> Wait, when I proposed you to
On Thu, 20 Dec 2018 18:04:25 + Dmitry Bogatov
wrote:
> ... What do you think about state of
> salsa:runit-team/runit, commit a8d698d? I am considering uploading it to
> unstable.
Wait, when I proposed you to move the start of sysv scripts to stage 2 I
completely
forgot about runit-sysv and ru
On Thu, 20 Dec 2018 18:04:25 + Dmitry Bogatov
wrote:
> ... What do you think about state of
> salsa:runit-team/runit, commit a8d698d? I am considering uploading it to
> unstable.
It should solve this bug, and also having a 90 sec timeout looks like a
final
solution to any misbehaving daemon
[2018-12-19 10:32] Lorenz
> Hi !
Hi!
> We are approaching the freeze, and I think that the state of runit
> about 'sulogin' is acceptable but not optimal: there are two minor
> issues unresolved.
Yes, we definitely should resolve them.
> > Glancing over the changes, changing the runsvdir is
Hi !
We are approaching the freeze, and I think that the state of runit about
'sulogin' is
acceptable but not optimal: there are two minor issues unresolved
[2018-11-09 01:09] alecfeld...@disroot.org
> Glancing over the changes, changing the runsvdir is a bad idea, since
> now stage 3 won't stop
Could you please keep width of your text below 72?
[2018-11-13 16:28] alecfeld...@disroot.org
> It is quite strange how debian uses /etc/service to store currently
> active services. Other distributions use /run/runit or /var/service,
> though /run makes more sense. Perhaps /etc/service could b
It is quite strange how debian uses /etc/service to store currently active
services. Other
distributions use /run/runit or /var/service, though /run makes more sense.
Perhaps /etc/service
could be moved somewhere else? This would solve the issue with etc being
read-only. The concept of
symlinks
Please keep BTS in CC.
[2018-11-09 22:35] alecfeld...@disroot.org
> If you look at the changes I made to stage 2, changing back to default
> won't be a problem.
>
> runlevel=default
> for arg in $(cat /proc/cmdline); do
> if [ -d /etc/runit/runsvdir/"$arg" ]; then
> echo "Runlevel d
control: reopen -1
[2018-11-09 01:09] alecfeld...@disroot.org
> Glancing over the changes, changing the runsvdir is a bad idea, since
> now stage 3 won't stop t he correct services.
>
> sv force-stop /etc/service/*
> sv exit /etc/service/*
Good catch. It need to be changed too. But I consider
[2018-11-06 17:37] alecfeld...@disroot.org
> By patch, do you mean the service itself? I've attached it here.
> The configuration changes are quite small.
I believe I solved issue, but a bit different. I am relucant to
rely so deeply on content of virtual filesystems, so sulogin will be started
[2018-11-05 03:58] alecfeld...@disroot.org
> Dear Maintainer,
Hello.
> When using the "single" kernel parameter, sulogin is started in stage 1.
> Signals only work in stage 2, and so reboot and shutdown commands don't work.
Yes, it is unfortunate; I believe crude `halt -f' still should work,
s
Package: runit
Version: 2.1.2-17
Severity: normal
Dear Maintainer,
When using the "single" kernel parameter, sulogin is started in stage 1.
Signals only work in stage 2, and so reboot and shutdown commands don't work.
In order to rectify this problem, I implemented Void Linux's solution, where
cu
12 matches
Mail list logo
