| Summary: | halt.sh should check for /dev/initctl when in vserver (openrc-0.2.5) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Romain Riviere <gentoo> |
| Component: | [OLD] Core system | Assignee: | Gentoo VPS Team (OBSOLETE) <vserver-devs+disabled> |
| Status: | RESOLVED INVALID | ||
| Severity: | minor | CC: | matthias |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Adaptation of the baselayout-1.13.0 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 ? |
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