* runit upgrades and halt rather than reboot @ 2006-02-02 4:20 Vincent Danen 2006-02-03 15:40 ` Gerrit Pape 0 siblings, 1 reply; 15+ messages in thread From: Vincent Danen @ 2006-02-02 4:20 UTC (permalink / raw) [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: runit upgrades and halt rather than reboot 2006-02-02 4:20 runit upgrades and halt rather than reboot Vincent Danen @ 2006-02-03 15:40 ` Gerrit Pape 2006-02-03 16:45 ` Vincent Danen 0 siblings, 1 reply; 15+ messages in thread From: Gerrit Pape @ 2006-02-03 15:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: runit upgrades and halt rather than reboot 2006-02-03 15:40 ` Gerrit Pape @ 2006-02-03 16:45 ` Vincent Danen 2006-02-03 16:55 ` Gerrit Pape 0 siblings, 1 reply; 15+ messages in thread From: Vincent Danen @ 2006-02-03 16:45 UTC (permalink / raw) [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: runit upgrades and halt rather than reboot 2006-02-03 16:45 ` Vincent Danen @ 2006-02-03 16:55 ` Gerrit Pape 2006-02-03 17:04 ` Vincent Danen 2006-02-11 19:03 ` Vincent Danen 0 siblings, 2 replies; 15+ messages in thread From: Gerrit Pape @ 2006-02-03 16:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: runit upgrades and halt rather than reboot 2006-02-03 16:55 ` Gerrit Pape @ 2006-02-03 17:04 ` Vincent Danen 2006-02-11 19:03 ` Vincent Danen 1 sibling, 0 replies; 15+ messages in thread From: Vincent Danen @ 2006-02-03 17:04 UTC (permalink / raw) [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: runit upgrades and halt rather than reboot 2006-02-03 16:55 ` Gerrit Pape 2006-02-03 17:04 ` Vincent Danen @ 2006-02-11 19:03 ` Vincent Danen 2006-02-11 19:11 ` Paul Jarc 1 sibling, 1 reply; 15+ messages in thread From: Vincent Danen @ 2006-02-11 19:03 UTC (permalink / raw) [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: runit upgrades and halt rather than reboot 2006-02-11 19:03 ` Vincent Danen @ 2006-02-11 19:11 ` Paul Jarc 2006-02-11 19:44 ` Vincent Danen 0 siblings, 1 reply; 15+ messages in thread From: Paul Jarc @ 2006-02-11 19:11 UTC (permalink / raw) Cc: supervision 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: runit upgrades and halt rather than reboot 2006-02-11 19:11 ` Paul Jarc @ 2006-02-11 19:44 ` Vincent Danen 2006-02-13 14:44 ` Gerrit Pape 0 siblings, 1 reply; 15+ messages in thread From: Vincent Danen @ 2006-02-11 19:44 UTC (permalink / raw) [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: runit upgrades and halt rather than reboot 2006-02-11 19:44 ` Vincent Danen @ 2006-02-13 14:44 ` Gerrit Pape 2006-02-14 4:08 ` Vincent Danen 0 siblings, 1 reply; 15+ messages in thread From: Gerrit Pape @ 2006-02-13 14:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: runit upgrades and halt rather than reboot 2006-02-13 14:44 ` Gerrit Pape @ 2006-02-14 4:08 ` Vincent Danen 2006-02-14 5:22 ` Joshua N Pritikin 2006-02-14 5:42 ` copy runit-init to /sbin/init or not Alex Efros 0 siblings, 2 replies; 15+ messages in thread From: Vincent Danen @ 2006-02-14 4:08 UTC (permalink / raw) [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: runit upgrades and halt rather than reboot 2006-02-14 4:08 ` Vincent Danen @ 2006-02-14 5:22 ` Joshua N Pritikin 2006-02-14 5:42 ` copy runit-init to /sbin/init or not Alex Efros 1 sibling, 0 replies; 15+ messages in thread From: Joshua N Pritikin @ 2006-02-14 5:22 UTC (permalink / raw) [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* copy runit-init to /sbin/init or not 2006-02-14 4:08 ` Vincent Danen 2006-02-14 5:22 ` Joshua N Pritikin @ 2006-02-14 5:42 ` Alex Efros 2006-02-14 6:04 ` Vincent Danen 1 sibling, 1 reply; 15+ messages in thread From: Alex Efros @ 2006-02-14 5:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: copy runit-init to /sbin/init or not 2006-02-14 5:42 ` copy runit-init to /sbin/init or not Alex Efros @ 2006-02-14 6:04 ` Vincent Danen 2006-02-14 14:08 ` Alex Efros 0 siblings, 1 reply; 15+ messages in thread From: Vincent Danen @ 2006-02-14 6:04 UTC (permalink / raw) [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: copy runit-init to /sbin/init or not 2006-02-14 6:04 ` Vincent Danen @ 2006-02-14 14:08 ` Alex Efros 2006-02-14 18:49 ` Vincent Danen 0 siblings, 1 reply; 15+ messages in thread From: Alex Efros @ 2006-02-14 14:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: copy runit-init to /sbin/init or not 2006-02-14 14:08 ` Alex Efros @ 2006-02-14 18:49 ` Vincent Danen 0 siblings, 0 replies; 15+ messages in thread From: Vincent Danen @ 2006-02-14 18:49 UTC (permalink / raw) [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2006-02-14 18:49 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-02-02 4:20 runit upgrades and halt rather than reboot Vincent Danen 2006-02-03 15:40 ` Gerrit Pape 2006-02-03 16:45 ` Vincent Danen 2006-02-03 16:55 ` Gerrit Pape 2006-02-03 17:04 ` Vincent Danen 2006-02-11 19:03 ` Vincent Danen 2006-02-11 19:11 ` Paul Jarc 2006-02-11 19:44 ` Vincent Danen 2006-02-13 14:44 ` Gerrit Pape 2006-02-14 4:08 ` Vincent Danen 2006-02-14 5:22 ` Joshua N Pritikin 2006-02-14 5:42 ` copy runit-init to /sbin/init or not Alex Efros 2006-02-14 6:04 ` Vincent Danen 2006-02-14 14:08 ` Alex Efros 2006-02-14 18:49 ` Vincent Danen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).