When stopping a baselayout-2 vserver, we get this : WARNING: could not determine runlevel - doing soft halt (it's better to use shutdown instead of halt from the command line) shutdown: /dev/initctl: No such file or directory init: /dev/initctl: No such file or directory /usr/lib/util-vserver/vserver.stop: line 96: 11371 Killed "${NICE_CMD[@]}" "${CHBIND_CMD[@]}" "$_VSPACE" --enter "$S_CONTEXT" "${OPTS_VSPACE[@]}" -- "$_VTAG" --migrate "${OPTS_VTAG_ENTER[@]}" --silent -- $_VCONTEXT $SILENT_OPT --migrate --chroot --xid "$S_CONTEXT" -- "${INITCMD_STOP[@]}" In openrc-0.2.5, halt.sh should check whether /dev/initctl exists. A patch was submitted for baselayout-1.13.0 to correct the same problem (see below). A very similar patch could be made for openrc. I'll try to upload a suggestion soon. Reproducible: Always Steps to Reproduce: Patch for baselayout-1.13.0 : http://people.linux-vserver.org/~hollow/baselayout-1.13.0-gentoo-init-style-fixes.patch
Created attachment 161010 [details, diff] Adaptation of the baselayout-1.13.0 patch Here's my humble attempt at generating a patch for this particular problem. "Works for me" (tm) so far.
if you halt from inside you need "halt -f", if you stop from outside make sure shutdown.sh is not overriden on sysvinit upgrade, openrc can do nothing here
(In reply to comment #2) > if you halt from inside you need "halt -f", if you stop from outside make sure > shutdown.sh is not overriden on sysvinit upgrade, openrc can do nothing here My shutdown.sh is still the one from sysvinit, however I'm not too sure about this inside/outside thing. I am stopping the vserver from the outside, but it is running the scripts in its own context, and calling halt.sh as part of the shutdown process if I get this right. It seems to me that either shutdown.sh shouldn't be called in the case of a vserver, or maybe it should be called directly with -f. Either way, isn't this openrc's halt.sh decision ?
*** Bug 232716 has been marked as a duplicate of this bug. ***
which init style are you using? (/etc/vservers/foo/apps/init/style)
sorry... gentoo style!
Same for me by the way : gentoo style all the way.
i guess this got broken with the sysvinit upgrade, please try to run the following command on the host: /usr/lib/util-vserver/distributions/gentoo/initpost /etc/vservers/foo /usr/lib/util-vserver/util-vserver-vars this should fix shutdown problems, otherwise reopen this bug
(In reply to comment #8) > i guess this got broken with the sysvinit upgrade, please try to run the > following command on the host: > > /usr/lib/util-vserver/distributions/gentoo/initpost /etc/vservers/foo > /usr/lib/util-vserver/util-vserver-vars > > this should fix shutdown problems, otherwise reopen this bug Brilliant ! That did it, thanks :-) There are a few "mkdir" that don't go to /dev/null in the script though, but that's cosmetic. More importantly though, does this mean that sysvinit should never be emerged (even updated) inside a vserver ? Unless I missed it and/or did something wrong, I could not have known that beforehand.
(In reply to comment #9) > More importantly though, does this mean that sysvinit should never be emerged > (even updated) inside a vserver? no, it means you should not replace shutdown.sh/reboot.sh during etc-update
(In reply to comment #10) > (In reply to comment #9) > > More importantly though, does this mean that sysvinit should never be emerged > > (even updated) inside a vserver? > > no, it means you should not replace shutdown.sh/reboot.sh during etc-update Point taken. Yet, seeing how openrc already makes decisions on what to do based on whether it's running inside a VServer or not, why not let it decide *NOT* to run shutdown.sh in case of a VServer ? I thought one of the advantages of baselayout-2 / openrc was that we wouldn't need a baselayout-vserver anymore. What's the point if we have to overwrite stuff from sysvinit ?
