runit upgrades and halt rather than reboot

runit upgrades and halt rather than reboot

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

I'm encountering a really odd problem.  When I upgrade runit, when I do
a "reboot" or "init 6", runit goes into poweroff mode rather than
reboot.  I'm gearing up to put out my next version of Annvix so am doing
some testing and we upgraded from runit 1.3.1 to 1.3.3 and on each test
instance (2 x86 and 1 x86_64), once all the packages were upgraded
(including runit), when I did reboot (the first two) and "init 6" (the
last one), they powered off.

I'm not sure if this is because the /sbin/init binary changed or what,
but it's *really* annoying, particularly since I know some folks who use
Annvix at remote locations (myself as well) and a trip to the colo to
turn the machine on after the upgrade would, well, stink.  =)

Any ideas as to what might be the problem and how I can rectify it?
After that reboot, runit is fine... reboot works as advertised, as does
halt, etc.  But it's just that one reboot after it's been upgraded that
is problematic.

Thanks much in advance.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

Re: runit upgrades and halt rather than reboot

[Gerrit Pape]

On Wed, Feb 01, 2006 at 09:20:50PM -0700, Vincent Danen wrote:
> I'm encountering a really odd problem.  When I upgrade runit, when I do
> a "reboot" or "init 6", runit goes into poweroff mode rather than
> reboot.  I'm gearing up to put out my next version of Annvix so am doing
> some testing and we upgraded from runit 1.3.1 to 1.3.3 and on each test
> instance (2 x86 and 1 x86_64), once all the packages were upgraded
> (including runit), when I did reboot (the first two) and "init 6" (the
> last one), they powered off.
> 
> I'm not sure if this is because the /sbin/init binary changed or what,
> but it's *really* annoying, particularly since I know some folks who use
> Annvix at remote locations (myself as well) and a trip to the colo to
> turn the machine on after the upgrade would, well, stink.  =)
> 
> Any ideas as to what might be the problem and how I can rectify it?
> After that reboot, runit is fine... reboot works as advertised, as does
> halt, etc.  But it's just that one reboot after it's been upgraded that
> is problematic.

I'm not sure from your description.  With a preliminary runit Debian
package, on shutdown after package upgrade, the root filesystem wasn't
unmounted cleanly, because /sbin/runit was replaced.  The workaround is
to first copy /sbin/runit to /sbin/runit.old, then replace /sbin/runit.
After reboot, /sbin/runit.old can be removed again.  Maybe it's worth a
try.

HTH, Gerrit.

Re: runit upgrades and halt rather than reboot

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

* Gerrit Pape <pape@smarden.org> [2006-02-03 15:40:31 +0000]:

> > I'm encountering a really odd problem.  When I upgrade runit, when I do
> > a "reboot" or "init 6", runit goes into poweroff mode rather than
> > reboot.  I'm gearing up to put out my next version of Annvix so am doing
> > some testing and we upgraded from runit 1.3.1 to 1.3.3 and on each test
> > instance (2 x86 and 1 x86_64), once all the packages were upgraded
> > (including runit), when I did reboot (the first two) and "init 6" (the
> > last one), they powered off.
> > 
> > I'm not sure if this is because the /sbin/init binary changed or what,
> > but it's *really* annoying, particularly since I know some folks who use
> > Annvix at remote locations (myself as well) and a trip to the colo to
> > turn the machine on after the upgrade would, well, stink.  =)
> > 
> > Any ideas as to what might be the problem and how I can rectify it?
> > After that reboot, runit is fine... reboot works as advertised, as does
> > halt, etc.  But it's just that one reboot after it's been upgraded that
> > is problematic.
> 
> I'm not sure from your description.  With a preliminary runit Debian
> package, on shutdown after package upgrade, the root filesystem wasn't
> unmounted cleanly, because /sbin/runit was replaced.  The workaround is
> to first copy /sbin/runit to /sbin/runit.old, then replace /sbin/runit.
> After reboot, /sbin/runit.old can be removed again.  Maybe it's worth a
> try.

Hmmm...  that might not be a bad idea to try.  So instead of running
reboot/halt/shutdown, run "init.old 6" (I renamed runit to init).

I'll give that a try, Gerrit.  It makes things a bit messy, but nothing
a startup script can't check for and cleanup.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

Re: runit upgrades and halt rather than reboot

[Gerrit Pape]

On Fri, Feb 03, 2006 at 09:45:29AM -0700, Vincent Danen wrote:
> * Gerrit Pape <pape@smarden.org> [2006-02-03 15:40:31 +0000]:
> > > I'm encountering a really odd problem.  When I upgrade runit, when I do
> > > a "reboot" or "init 6", runit goes into poweroff mode rather than
> > > reboot.  I'm gearing up to put out my next version of Annvix so am doing
> > > some testing and we upgraded from runit 1.3.1 to 1.3.3 and on each test
> > > instance (2 x86 and 1 x86_64), once all the packages were upgraded
> > > (including runit), when I did reboot (the first two) and "init 6" (the
> > > last one), they powered off.
> > > 
> > > I'm not sure if this is because the /sbin/init binary changed or what,
> > > but it's *really* annoying, particularly since I know some folks who use
> > > Annvix at remote locations (myself as well) and a trip to the colo to
> > > turn the machine on after the upgrade would, well, stink.  =)
> > > 
> > > Any ideas as to what might be the problem and how I can rectify it?
> > > After that reboot, runit is fine... reboot works as advertised, as does
> > > halt, etc.  But it's just that one reboot after it's been upgraded that
> > > is problematic.
> > 
> > I'm not sure from your description.  With a preliminary runit Debian
> > package, on shutdown after package upgrade, the root filesystem wasn't
> > unmounted cleanly, because /sbin/runit was replaced.  The workaround is
> > to first copy /sbin/runit to /sbin/runit.old, then replace /sbin/runit.
> > After reboot, /sbin/runit.old can be removed again.  Maybe it's worth a
> > try.
> 
> Hmmm...  that might not be a bad idea to try.  So instead of running
> reboot/halt/shutdown, run "init.old 6" (I renamed runit to init).

No, you can still use `init 6` with the new binary.  It's just that the
old, still running, /sbin/init still has an inode on the filesystem;
that's what the copy is for.  I'm not sure it solves your problem
though.

> I'll give that a try, Gerrit.  It makes things a bit messy, but nothing
> a startup script can't check for and cleanup.

I have this in /etc/runit/1
 rm -f /sbin/runit.old

Regards, Gerrit.

Re: runit upgrades and halt rather than reboot

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]

* Gerrit Pape <pape@smarden.org> [2006-02-03 16:55:52 +0000]:

> > > > I'm encountering a really odd problem.  When I upgrade runit, when I do
> > > > a "reboot" or "init 6", runit goes into poweroff mode rather than
> > > > reboot.  I'm gearing up to put out my next version of Annvix so am doing
> > > > some testing and we upgraded from runit 1.3.1 to 1.3.3 and on each test
> > > > instance (2 x86 and 1 x86_64), once all the packages were upgraded
> > > > (including runit), when I did reboot (the first two) and "init 6" (the
> > > > last one), they powered off.
> > > > 
> > > > I'm not sure if this is because the /sbin/init binary changed or what,
> > > > but it's *really* annoying, particularly since I know some folks who use
> > > > Annvix at remote locations (myself as well) and a trip to the colo to
> > > > turn the machine on after the upgrade would, well, stink.  =)
> > > > 
> > > > Any ideas as to what might be the problem and how I can rectify it?
> > > > After that reboot, runit is fine... reboot works as advertised, as does
> > > > halt, etc.  But it's just that one reboot after it's been upgraded that
> > > > is problematic.
> > > 
> > > I'm not sure from your description.  With a preliminary runit Debian
> > > package, on shutdown after package upgrade, the root filesystem wasn't
> > > unmounted cleanly, because /sbin/runit was replaced.  The workaround is
> > > to first copy /sbin/runit to /sbin/runit.old, then replace /sbin/runit.
> > > After reboot, /sbin/runit.old can be removed again.  Maybe it's worth a
> > > try.
> > 
> > Hmmm...  that might not be a bad idea to try.  So instead of running
> > reboot/halt/shutdown, run "init.old 6" (I renamed runit to init).
> 
> No, you can still use `init 6` with the new binary.  It's just that the
> old, still running, /sbin/init still has an inode on the filesystem;
> that's what the copy is for.  I'm not sure it solves your problem
> though.

Ahhh... ok, I see what you're saying.  Well, I'll give it a go both ways
(that's what vmware states are for) and see what happens.

> > I'll give that a try, Gerrit.  It makes things a bit messy, but nothing
> > a startup script can't check for and cleanup.
> 
> I have this in /etc/runit/1
>  rm -f /sbin/runit.old

That's what I was thinking of doing as well.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

Re: runit upgrades and halt rather than reboot

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 3709 bytes --]

* Gerrit Pape <pape@smarden.org> [2006-02-03 16:55:52 +0000]:

> > > > I'm encountering a really odd problem.  When I upgrade runit, when I do
> > > > a "reboot" or "init 6", runit goes into poweroff mode rather than
> > > > reboot.  I'm gearing up to put out my next version of Annvix so am doing
> > > > some testing and we upgraded from runit 1.3.1 to 1.3.3 and on each test
> > > > instance (2 x86 and 1 x86_64), once all the packages were upgraded
> > > > (including runit), when I did reboot (the first two) and "init 6" (the
> > > > last one), they powered off.
> > > > 
> > > > I'm not sure if this is because the /sbin/init binary changed or what,
> > > > but it's *really* annoying, particularly since I know some folks who use
> > > > Annvix at remote locations (myself as well) and a trip to the colo to
> > > > turn the machine on after the upgrade would, well, stink.  =)
> > > > 
> > > > Any ideas as to what might be the problem and how I can rectify it?
> > > > After that reboot, runit is fine... reboot works as advertised, as does
> > > > halt, etc.  But it's just that one reboot after it's been upgraded that
> > > > is problematic.
> > > 
> > > I'm not sure from your description.  With a preliminary runit Debian
> > > package, on shutdown after package upgrade, the root filesystem wasn't
> > > unmounted cleanly, because /sbin/runit was replaced.  The workaround is
> > > to first copy /sbin/runit to /sbin/runit.old, then replace /sbin/runit.
> > > After reboot, /sbin/runit.old can be removed again.  Maybe it's worth a
> > > try.
> > 
> > Hmmm...  that might not be a bad idea to try.  So instead of running
> > reboot/halt/shutdown, run "init.old 6" (I renamed runit to init).
> 
> No, you can still use `init 6` with the new binary.  It's just that the
> old, still running, /sbin/init still has an inode on the filesystem;
> that's what the copy is for.  I'm not sure it solves your problem
> though.

Ok, maybe I'm missing something, but the inode is different on the copy.

[root@cerberus sbin]# cp init init.org
[root@cerberus sbin]# ls -i init init.org
6374308 init*  6301334 init.org*

But then if I do:

[root@cerberus sbin]# cp /bin/ls init.org
[root@cerberus sbin]# ls -i init.org
6301334 init.org*

So even though the contents of init.org have drastically changed, the
inode is still the same.  The same would obviously hold true for init,
when it's replaced during an rpm upgrade.

I don't think it solves the problem (I did try a few days ago and it
still halted the system), but maybe this explains the why; the copy
apparently isn't needed it we're trying to preserve the inode, or is
there a way to copy a file by specifying the inode?  I'll admit I'm a
bit out of my depth on this one (no options seemed to present themself
from cp --help).

If there is one thing that is problematic for me (and Annvix users) is
that runit, when it is upgraded, always halts the system.  There has to
be a way to fix this.  It's my one last great bug.  =)

Any ideas at all, from anyone, would be greatly appreciated.

> > I'll give that a try, Gerrit.  It makes things a bit messy, but nothing
> > a startup script can't check for and cleanup.
> 
> I have this in /etc/runit/1
>  rm -f /sbin/runit.old

Yup, that would do it, but I'm not convinced the old file makes a
difference.  I'm going to try again (via the rpm package rather than
manually copying) to see if it makes a difference.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

Re: runit upgrades and halt rather than reboot

[Paul Jarc]

Vincent Danen <vdanen@linsec.ca> wrote:
> [root@cerberus sbin]# cp init init.org
> [root@cerberus sbin]# ls -i init init.org
> 6374308 init*  6301334 init.org*

Make a hard link instead of a copy:
# ln init init.org


paul

Re: runit upgrades and halt rather than reboot

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

* Paul Jarc <prj@po.cwru.edu> [2006-02-11 14:11:21 -0500]:

> Vincent Danen <vdanen@linsec.ca> wrote:
> > [root@cerberus sbin]# cp init init.org
> > [root@cerberus sbin]# ls -i init init.org
> > 6374308 init*  6301334 init.org*
> 
> Make a hard link instead of a copy:
> # ln init init.org

Nice that works, thanks.  Forgot about hard links.

Anyways, it still doesn't work.  Tried a bunch of times and a bunch of
different things:

1) cp /sbin/init to /sbin/init.old before upgrade; use reboot
2) cp /sbin/init to /sbin/init.old before upgrade; use init.old 6
3) ln /sbin/init to /sbin/init.old before upgrade; use reboot
4) ln /sbin/init to /sbin/init.old before upgrade; use init.old 6

in all cases, this didn't work.

I was also mistaken in an earlier post... I do not move runit to init,
but rather runit-init to init (runit stays as is).  So thinking that
might have something to do with it, I moved runit to init and then it
just plain old wouldn't let me do anything (fatal: needs to be process 1
or something similar); got that from running "runit 6", "init 6", and
"reboot".  So I think I need to have runit-init remain as init and have
it exec runit.

Could that be part of the problem?  If so, why won't runit behave if
it's renamed to init?

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

Re: runit upgrades and halt rather than reboot

[Gerrit Pape]

On Sat, Feb 11, 2006 at 12:44:45PM -0700, Vincent Danen wrote:
> * Paul Jarc <prj@po.cwru.edu> [2006-02-11 14:11:21 -0500]:
> 
> > Vincent Danen <vdanen@linsec.ca> wrote:
> > > [root@cerberus sbin]# cp init init.org
> > > [root@cerberus sbin]# ls -i init init.org
> > > 6374308 init*  6301334 init.org*
> > 
> > Make a hard link instead of a copy:
> > # ln init init.org
> 
> Nice that works, thanks.  Forgot about hard links.
> 
> Anyways, it still doesn't work.  Tried a bunch of times and a bunch of
> different things:
> 
> 1) cp /sbin/init to /sbin/init.old before upgrade; use reboot
> 2) cp /sbin/init to /sbin/init.old before upgrade; use init.old 6
> 3) ln /sbin/init to /sbin/init.old before upgrade; use reboot
> 4) ln /sbin/init to /sbin/init.old before upgrade; use init.old 6
> 
> in all cases, this didn't work.

Try ln /sbin/runit to /sbin/runit.old.

> I was also mistaken in an earlier post... I do not move runit to init,
> but rather runit-init to init (runit stays as is).  So thinking that
> might have something to do with it, I moved runit to init and then it
> just plain old wouldn't let me do anything (fatal: needs to be process 1
> or something similar); got that from running "runit 6", "init 6", and
> "reboot".  So I think I need to have runit-init remain as init and have
> it exec runit.

Yes, runit-init must be /sbin/init.  It's that /sbin/init on unix is not
only used as process 1, but also as command line interface while the
system is up (e.g. 'init 0', 'init 6').  With runit, the process no 1
duties are implemented in the runit program, and the cli in runit-init.
runit-init is installed as /sbin/init, and if it sees itself started
with pid 1, it immediately replaces itself with /sbin/runit, the process
no 1 implementation.  If it's not running as pid 1, it's the command
line interface to signal the (currently as process no 1 running) runit
process.

Regards, Gerrit.

Re: runit upgrades and halt rather than reboot

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 2511 bytes --]

* Gerrit Pape <pape@smarden.org> [2006-02-13 14:44:31 +0000]:

> > > > [root@cerberus sbin]# cp init init.org
> > > > [root@cerberus sbin]# ls -i init init.org
> > > > 6374308 init*  6301334 init.org*
> > > 
> > > Make a hard link instead of a copy:
> > > # ln init init.org
> > 
> > Nice that works, thanks.  Forgot about hard links.
> > 
> > Anyways, it still doesn't work.  Tried a bunch of times and a bunch of
> > different things:
> > 
> > 1) cp /sbin/init to /sbin/init.old before upgrade; use reboot
> > 2) cp /sbin/init to /sbin/init.old before upgrade; use init.old 6
> > 3) ln /sbin/init to /sbin/init.old before upgrade; use reboot
> > 4) ln /sbin/init to /sbin/init.old before upgrade; use init.old 6
> > 
> > in all cases, this didn't work.
> 
> Try ln /sbin/runit to /sbin/runit.old.

YES!  That worked perfectly.  Tried it in vmware and a few machines and
it's absolutely fantastic.  Thank you!!

> > I was also mistaken in an earlier post... I do not move runit to init,
> > but rather runit-init to init (runit stays as is).  So thinking that
> > might have something to do with it, I moved runit to init and then it
> > just plain old wouldn't let me do anything (fatal: needs to be process 1
> > or something similar); got that from running "runit 6", "init 6", and
> > "reboot".  So I think I need to have runit-init remain as init and have
> > it exec runit.
> 
> Yes, runit-init must be /sbin/init.  It's that /sbin/init on unix is not
> only used as process 1, but also as command line interface while the
> system is up (e.g. 'init 0', 'init 6').  With runit, the process no 1
> duties are implemented in the runit program, and the cli in runit-init.
> runit-init is installed as /sbin/init, and if it sees itself started
> with pid 1, it immediately replaces itself with /sbin/runit, the process
> no 1 implementation.  If it's not running as pid 1, it's the command
> line interface to signal the (currently as process no 1 running) runit
> process.

This makes sense to me, now that I understand what runit-init actually
does.

Absolutely fantastic, Gerrit.  Thank you very much both for your
assistance and for runit itself.

If I ever make any money off Annvix, some of it is most definitely
heading your way.  =)

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

Re: runit upgrades and halt rather than reboot

[Joshua N Pritikin]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Mon, Feb 13, 2006 at 09:08:31PM -0700, Vincent Danen wrote:
> Absolutely fantastic, Gerrit.  Thank you very much both for your
> assistance and for runit itself.
> 
> If I ever make any money off Annvix, some of it is most definitely
> heading your way.  =)

To me, an obvious application for runit & dietlibc is the One Laptop Per
Child project.  Those machines will be reasonably fast but memory
starved.

--
Make April 15 just another day, visit http://fairtax.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

copy runit-init to /sbin/init or not

[Alex Efros]

Hi!

> * Gerrit Pape <pape@smarden.org> [2006-02-13 14:44:31 +0000]:
> > Yes, runit-init must be /sbin/init.  It's that /sbin/init on unix is not
> > only used as process 1, but also as command line interface while the
> > system is up (e.g. 'init 0', 'init 6').  With runit, the process no 1
> > duties are implemented in the runit program, and the cli in runit-init.
> > runit-init is installed as /sbin/init, and if it sees itself started
> > with pid 1, it immediately replaces itself with /sbin/runit, the process
> > no 1 implementation.  If it's not running as pid 1, it's the command
> > line interface to signal the (currently as process no 1 running) runit
> > process.

Do you aware of any software which run 'init [0|6]' or 'halt' or 'reboot'?
For now I've seen these commands executed only manually by root and by
acpid daemon.

I've problems with installing runit-init as /sbin/init on my Gentoo - this
is because from time to time while upgrading overall system 'sysvinit' package
become upgraded and it replace /sbin/init. If I forget to replace it
by runit-init manually again, I got surprise on next reboot. :-(

Currently I work around this issue this way:
- /sbin/{init,halt,reboot} is sysvinit's
- kernel boot with param init=/sbin/runit-init
- there aliases configured in /root/.bashrc:
    alias reboot='/sbin/runit-init 6'
    alias halt='/sbin/runit-init 0'
  (I usually use reboot|halt, not init 0|6, but alias for init also can be
  added if needed)
- acpid configured to run '/sbin/runit-init 0' in it /etc/acpi/default.sh

-- 
			WBR, Alex.

Re: copy runit-init to /sbin/init or not

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]

* Alex Efros <powerman@powerman.asdfGroup.com> [2006-02-14 07:42:51 +0200]:

> > * Gerrit Pape <pape@smarden.org> [2006-02-13 14:44:31 +0000]:
> > > Yes, runit-init must be /sbin/init.  It's that /sbin/init on unix is not
> > > only used as process 1, but also as command line interface while the
> > > system is up (e.g. 'init 0', 'init 6').  With runit, the process no 1
> > > duties are implemented in the runit program, and the cli in runit-init.
> > > runit-init is installed as /sbin/init, and if it sees itself started
> > > with pid 1, it immediately replaces itself with /sbin/runit, the process
> > > no 1 implementation.  If it's not running as pid 1, it's the command
> > > line interface to signal the (currently as process no 1 running) runit
> > > process.
> 
> Do you aware of any software which run 'init [0|6]' or 'halt' or 'reboot'?
> For now I've seen these commands executed only manually by root and by
> acpid daemon.

AFAIK, programs like apcupsd and nut probably do.  Not aware of any
others, however.

> I've problems with installing runit-init as /sbin/init on my Gentoo - this
> is because from time to time while upgrading overall system 'sysvinit' package
> become upgraded and it replace /sbin/init. If I forget to replace it
> by runit-init manually again, I got surprise on next reboot. :-(

Doesn't Gentoo have a blacklist?  Ie. tell it not to emerge a new
sysvinit if it comes across one?  That would be my first suggestion.  I
seriously doubt that shutdown/reboot/halt really need to be recompiled
that often.

> Currently I work around this issue this way:
> - /sbin/{init,halt,reboot} is sysvinit's
> - kernel boot with param init=/sbin/runit-init
> - there aliases configured in /root/.bashrc:
>     alias reboot='/sbin/runit-init 6'
>     alias halt='/sbin/runit-init 0'
>   (I usually use reboot|halt, not init 0|6, but alias for init also can be
>   added if needed)
> - acpid configured to run '/sbin/runit-init 0' in it /etc/acpi/default.sh

You can still use sysvinit's shutdown/reboot/etc. with runit.  No need
for the aliases or even reconfigured acpid.  They'll work just fine.
You might get a sporadic "can't communicate with /dev/initctl" message
when you type reboot or halt, but that's not really a problem (I've just
patched that out for Annvix to prevent people from getting concerned
over nothing).

The solution of booting the kernel with init=/sbin/runit-init would work
in and of itself, if you can't blacklist sysvinit.  No need for the
aliases and other stuff.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

Re: copy runit-init to /sbin/init or not

[Alex Efros]

Hi!

On Mon, Feb 13, 2006 at 11:04:03PM -0700, Vincent Danen wrote:
> AFAIK, programs like apcupsd and nut probably do.  Not aware of any
> others, however.

Thanks, it has sense.

> Doesn't Gentoo have a blacklist?  Ie. tell it not to emerge a new
> sysvinit if it comes across one?  That would be my first suggestion.  I
> seriously doubt that shutdown/reboot/halt really need to be recompiled
> that often.

Hehehe. Gentoo wanna recompile everything from time to time, it just like
how compilation looks like... lines go up, CPU working, admin feel nervous... :)

I've tried to blacklist (package.mask in Gentoo terminology) sysvinit, but
then emerge start complaining what it unable to merge 'critical system
package'... ;-) Giving init= param to kernel sounds ease than fighting
with emerge from time to time.

> You can still use sysvinit's shutdown/reboot/etc. with runit.  No need
> for the aliases or even reconfigured acpid.  They'll work just fine.
> You might get a sporadic "can't communicate with /dev/initctl" message
> when you type reboot or halt, but that's not really a problem (I've just
> patched that out for Annvix to prevent people from getting concerned
> over nothing).
> 
> The solution of booting the kernel with init=/sbin/runit-init would work
> in and of itself, if you can't blacklist sysvinit.  No need for the
> aliases and other stuff.

Nope. I've just executed:

    home ~ # /sbin/reboot 
    WARNING: could not determine runlevel - doing soft reboot
      (it's better to use shutdown instead of reboot from the command line)

    Broadcast message from root (pts/5) (Tue Feb 14 16:05:34 2006):

    The system is going down for reboot NOW!
    shutdown: /dev/initctl: No such file or directory
    init: /dev/initctl: No such file or directory
    home ~ # /sbin/halt 
    WARNING: could not determine runlevel - doing soft halt
      (it's better to use shutdown instead of halt from the command line)

    Broadcast message from root (pts/5) (Tue Feb 14 16:05:37 2006):

    The system is going down for system halt NOW!
    shutdown: /dev/initctl: No such file or directory
    init: /dev/initctl: No such file or directory

and THEN go to write this email... guess what? it doesn't work (except
spamming all xterms with 'Broadcast message' - that is working). :-)

home ~ # ls -l /sbin/*nit* /sbin/reboot /sbin/halt 
-rwxr-xr-x  1 root root 14212 Янв 19 03:22 /sbin/halt
-rwxr-xr-x  1 root root 39216 Янв 19 03:22 /sbin/init
lrwxrwxrwx  1 root root     4 Янв 19 03:22 /sbin/reboot -> halt
-rwxr-xr-x  1 root root 23640 Янв 19 03:29 /sbin/runit
-rwxr-xr-x  1 root root 14896 Янв 19 03:29 /sbin/runit-init
lrwxrwxrwx  1 root root     4 Янв 19 03:22 /sbin/telinit -> init

-- 
			WBR, Alex.

Re: copy runit-init to /sbin/init or not

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]

* Alex Efros <powerman@powerman.asdfGroup.com> [2006-02-14 16:08:58 +0200]:

> > AFAIK, programs like apcupsd and nut probably do.  Not aware of any
> > others, however.
> 
> Thanks, it has sense.
> 
> > Doesn't Gentoo have a blacklist?  Ie. tell it not to emerge a new
> > sysvinit if it comes across one?  That would be my first suggestion.  I
> > seriously doubt that shutdown/reboot/halt really need to be recompiled
> > that often.
> 
> Hehehe. Gentoo wanna recompile everything from time to time, it just like
> how compilation looks like... lines go up, CPU working, admin feel nervous... :)

Never really used Gentoo, so can't say... =)  But unnecessary
recompiling seems a little silly to me.

> I've tried to blacklist (package.mask in Gentoo terminology) sysvinit, but
> then emerge start complaining what it unable to merge 'critical system
> package'... ;-) Giving init= param to kernel sounds ease than fighting
> with emerge from time to time.

You're right... passing init= is probably easier.

> > You can still use sysvinit's shutdown/reboot/etc. with runit.  No need
> > for the aliases or even reconfigured acpid.  They'll work just fine.
> > You might get a sporadic "can't communicate with /dev/initctl" message
> > when you type reboot or halt, but that's not really a problem (I've just
> > patched that out for Annvix to prevent people from getting concerned
> > over nothing).
> > 
> > The solution of booting the kernel with init=/sbin/runit-init would work
> > in and of itself, if you can't blacklist sysvinit.  No need for the
> > aliases and other stuff.
> 
> Nope. I've just executed:
> 
>     home ~ # /sbin/reboot 
>     WARNING: could not determine runlevel - doing soft reboot
>       (it's better to use shutdown instead of reboot from the command line)
> 
>     Broadcast message from root (pts/5) (Tue Feb 14 16:05:34 2006):
> 
>     The system is going down for reboot NOW!
>     shutdown: /dev/initctl: No such file or directory
>     init: /dev/initctl: No such file or directory
>     home ~ # /sbin/halt 
>     WARNING: could not determine runlevel - doing soft halt
>       (it's better to use shutdown instead of halt from the command line)
> 
>     Broadcast message from root (pts/5) (Tue Feb 14 16:05:37 2006):
> 
>     The system is going down for system halt NOW!
>     shutdown: /dev/initctl: No such file or directory
>     init: /dev/initctl: No such file or directory
> 
> and THEN go to write this email... guess what? it doesn't work (except
> spamming all xterms with 'Broadcast message' - that is working). :-)

Poking in my subversion rep here, I see I made a patch to workaround
that so I guess it doesn't work "out of the box".  It's the runlevel
issue that's the culprit.

The patch is here:

http://svn.annvix.org/cgi-bin/viewcvs.cgi/releases/1.2-CURRENT/SysVinit/SOURCES/sysvinit-2.85-avx-silent_no_runlevel.patch?root=packages&rev=4797&view=log

The problem is in halt.c it looks to see what runlevel you're in and if
you're *not* in runlevel 0 or 6, it'll do the reboot stuff.  Obviously
with runlevel reporting:

[vdanen@build ~]$ /sbin/runlevel 
unknown

it doesn't let you do much.  I just patched it to remove the checks for
the runlevel and it does work here.  Not sure how easy it is to put your
own custom patches into Gentoo tho.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]