Bug#638019: /run/initctl
El 9 de gener de 2012 0:10, Roger Leigh rle...@codelibre.net ha escrit: Please could you try the package at http://people.debian.org/~rleigh/sysvinit/sysvinit_2.88dsf-19.dsc Let me know if the postinst logic is acceptable to you. It works for me, and the increasing delay should work for all but the slowest/loaded systems. Works fine here (GNU/kFreeBSD). Thanks! -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
On Fri, Jan 06, 2012 at 03:25:53PM +0100, Robert Millan wrote: I didn't notice this was actually a Release Goal [1]. Tagging appropiately. I should note that the patch I sent has an unwanted side-effect: unability to send messages to init until after first reboot, which means first reboot can't be done cleanly. Maybe clients can be modified to attempt old path first then try with /run/initctl (or vice-versa), or update scripts could play some kind of symlink trick. I haven't had time to resolve this however. How about on upgrade we symlink /run/initctl → /dev/initctl if /run/initctl does not exist? Programs can therefore be switched to using /run/initctl immediately. On reboot, we can then just create /run/initctl and everything should just work. Does this sound OK, or have I missed something unobvious? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
On Sun, Jan 08, 2012 at 11:22:41AM +, Roger Leigh wrote:
On Fri, Jan 06, 2012 at 03:25:53PM +0100, Robert Millan wrote:
I didn't notice this was actually a Release Goal [1]. Tagging appropiately.
I should note that the patch I sent has an unwanted side-effect:
unability to send messages to init until after first reboot, which
means first reboot can't be done cleanly.
Maybe clients can be modified to attempt old path first then try with
/run/initctl (or vice-versa), or update scripts could play some kind
of symlink trick. I haven't had time to resolve this however.
How about on upgrade we symlink /run/initctl → /dev/initctl if
/run/initctl does not exist?
Programs can therefore be switched to using /run/initctl immediately.
On reboot, we can then just create /run/initctl and everything
should just work.
Does this sound OK, or have I missed something unobvious?
BTW, all of your upstream changes are already in sysvinit.git
(http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=blob_plain;f=debian/patches/93_run_initctl.patch;hb=a0263c14e64f0bbab10f656284272a8c9066189b)
I would propose something like the following, based on your
patch, would complete the migration (attached). Not yet tested.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
diff --git a/debian/patches/series b/debian/patches/series
index c8af391..7ac3e82 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -17,4 +17,5 @@
79_noninteractive_ignore_sigint.patch
91_sulogin_lockedpw.dpatch
92_kfreebsd_ifdown.patch
+93_run_initctl.patch
94_kfreebsd_xterm.patch
diff --git a/debian/postinst b/debian/postinst
index 10d77a2..d876704 100755
--- a/debian/postinst
+++ b/debian/postinst
@@ -16,18 +16,17 @@ esac
umask 022
+INITCTL=/run/initctl
case $(uname -s) in
*FreeBSD)
- INITCTL=/etc/.initctl
+ OLDINITCTL=/etc/.initctl
;;
*)
- INITCTL=/dev/initctl
+ OLDINITCTL=/dev/initctl
;;
esac
-#
-# Check /dev/initctl
-#
+# Create /run/initctl
if [ $INITCTL ] [ ! -p $INITCTL ]
then
echo sysvinit: creating $INITCTL
@@ -46,6 +45,12 @@ fi
#
init u ||:
+# Remove old pipe if present. No longer in use after re-exec.
+if [ $OLDINITCTL ] [ -p $OLDINITCTL ]
+then
+rm -f $OLDINITCTL
+fi
+
#DEBHELPER#
exit 0
diff --git a/debian/src/initscripts/etc/init.d/mountall.sh b/debian/src/initscripts/etc/init.d/mountall.sh
index 1daf994..033f9b8 100755
--- a/debian/src/initscripts/etc/init.d/mountall.sh
+++ b/debian/src/initscripts/etc/init.d/mountall.sh
@@ -43,26 +43,6 @@ do_start() {
fi
post_mountall
- case $(uname -s) in
- *FreeBSD)
- INITCTL=/etc/.initctl
- ;;
- *)
- INITCTL=/dev/initctl
- ;;
- esac
-
- #
- # We might have mounted something over /dev, see if
- # /dev/initctl is there. Look for /usr/share/sysvinit/update-rc.d
- # to verify that sysvinit (and not upstart) is installed).
- #
- if [ ! -p $INITCTL ] [ -f /usr/share/sysvinit/update-rc.d ]; then
- rm -f $INITCTL
- mknod -m 600 $INITCTL p
- kill -USR1 1
- fi
-
# Execute swapon command again, in case we want to swap to
# a file on a now mounted filesystem.
swaponagain 'swapfile'
Bug#638019: /run/initctl
Hi Roger, Thanks for looking at this. El 8 de gener de 2012 12:22, Roger Leigh rle...@debian.org ha escrit: How about on upgrade we symlink /run/initctl → /dev/initctl if /run/initctl does not exist? Programs can therefore be switched to using /run/initctl immediately. This seems fine, however... On reboot, we can then just create /run/initctl and everything should just work. ...you need to be more specific about what on reboot means. /sbin/init will open /run/initctl very early. If at that time /run/initctl is a symlink, it's no good replacing it with a real fifo afterwards (we get in the same situation we were before reboot). Or are you proposing that /sbin/init itself removes the symlink and creates a new fifo before opening it? Btw, your patch doesn't do what you described. Did you attach what you intended? -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
On Sun, Jan 08, 2012 at 01:51:03PM +0100, Robert Millan wrote: Hi Roger, Thanks for looking at this. El 8 de gener de 2012 12:22, Roger Leigh rle...@debian.org ha escrit: How about on upgrade we symlink /run/initctl → /dev/initctl if /run/initctl does not exist? Programs can therefore be switched to using /run/initctl immediately. This seems fine, however... On reboot, we can then just create /run/initctl and everything should just work. ...you need to be more specific about what on reboot means. /sbin/init will open /run/initctl very early. If at that time /run/initctl is a symlink, it's no good replacing it with a real fifo afterwards (we get in the same situation we were before reboot). Or are you proposing that /sbin/init itself removes the symlink and creates a new fifo before opening it? Btw, your patch doesn't do what you described. Did you attach what you intended? I thought about it a bit more, and the symlink is not needed. If we create /run/initctl and re-exec init, it will then open the new pipe. We can then delete the old one and the process is complete. This can be done entirely within the postinst, and is what the attached patch does. I assume /sbin/init creates /run/initctl at startup if it doesn't already exist? If not, we might need to create it in the initramfs and/or after startup in a similar manner to the existing handling of /dev/initctl. Not checked this--I'll have to look into it a bit more. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
El 8 de gener de 2012 14:15, Roger Leigh rle...@codelibre.net ha escrit: I thought about it a bit more, and the symlink is not needed. If we create /run/initctl and re-exec init, it will then open the new pipe. We can then delete the old one and the process is complete. This can be done entirely within the postinst, and is what the attached patch does. How do you tell init to re-exec when there's no initctl? HUP signal? If not, we might need to create it in the initramfs This wouldn't work on GNU/kFreeBSD (ramdisk is not used for disk boot). -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
On Sun, Jan 08, 2012 at 02:26:52PM +0100, Robert Millan wrote: El 8 de gener de 2012 14:15, Roger Leigh rle...@codelibre.net ha escrit: I thought about it a bit more, and the symlink is not needed. If we create /run/initctl and re-exec init, it will then open the new pipe. We can then delete the old one and the process is complete. This can be done entirely within the postinst, and is what the attached patch does. How do you tell init to re-exec when there's no initctl? HUP signal? The postinst currently calls init u, but I think that's problematic-- it would call the new binary using the new path. We can use SIGUSR1 to tell it to reopen the control channel. Maybe symlink /dev/initctl to /run/initctl and issue SIGUSR1, then issue init u to rexec? We would probably need a sleep between the two to give init a chance to open /run/initctl prior to issuing the init u. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
El 8 de gener de 2012 14:56, Roger Leigh rle...@codelibre.net ha escrit: The postinst currently calls init u, but I think that's problematic-- it would call the new binary using the new path. On the contrary, isn't this precisely what we wanted? No symlink needed then. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
El 8 de gener de 2012 15:00, Robert Millan r...@debian.org ha escrit: El 8 de gener de 2012 14:56, Roger Leigh rle...@codelibre.net ha escrit: The postinst currently calls init u, but I think that's problematic-- it would call the new binary using the new path. On the contrary, isn't this precisely what we wanted? No symlink needed then. Uhm, not sure if I understood correctly what init u does. Anyway, I'd propose this approach: - Create a new fifo in new path (no symlink). - Install new binaries (both sides) which use the new path. - Force init re-exec using a signal. It seems much simpler than messing with symlinks or adding on-reboot triggered actions. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
On Sun, Jan 08, 2012 at 03:01:57PM +0100, Robert Millan wrote: El 8 de gener de 2012 15:00, Robert Millan r...@debian.org ha escrit: El 8 de gener de 2012 14:56, Roger Leigh rle...@codelibre.net ha escrit: The postinst currently calls init u, but I think that's problematic-- it would call the new binary using the new path. On the contrary, isn't this precisely what we wanted? No symlink needed then. Uhm, not sure if I understood correctly what init u does. Anyway, I'd propose this approach: - Create a new fifo in new path (no symlink). - Install new binaries (both sides) which use the new path. - Force init re-exec using a signal. It seems much simpler than messing with symlinks or adding on-reboot triggered actions. The problem is that there isn't a signal to force a re-exec. You have to do it through the control pipe. init u sends the signal through the pipe to trigger the re-exec, which requires that the old pipe be present. Because the new binaries will use the new path, init u on its own won't work. I would suggest this strategy: 1) Create /run/initctl 2) Symlink /dev/initctl (or /etc/.initctl) to /run/initctl 3) Send SIGUSR1 to init → init reopens using the old path, but is redirected to use /run/initctl 4) Wait for that action to complete 5) Run init q to re-exec init. The new init will use the new paths 6) Delete the no-longer-needed /dev/initctl (or /etc/.initctl). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
El 8 de gener de 2012 15:14, Roger Leigh rle...@codelibre.net ha escrit: The problem is that there isn't a signal to force a re-exec. You have to do it through the control pipe. Ah I see. In retrospect, this seems like a bad decision. Well, gotta work with what we've got... init u sends the signal through the pipe to trigger the re-exec, which requires that the old pipe be present. Because the new binaries will use the new path, init u on its own won't work. I would suggest this strategy: 1) Create /run/initctl 2) Symlink /dev/initctl (or /etc/.initctl) to /run/initctl 3) Send SIGUSR1 to init → init reopens using the old path, but is redirected to use /run/initctl 4) Wait for that action to complete 5) Run init q to re-exec init. The new init will use the new paths 6) Delete the no-longer-needed /dev/initctl (or /etc/.initctl). Seems good, but I dislike step 4, as it opens the door for race conditions. Can't we just remove steps 4 and 5? I think everything would work without them. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
On Sun, Jan 08, 2012 at 03:34:13PM +0100, Robert Millan wrote: El 8 de gener de 2012 15:14, Roger Leigh rle...@codelibre.net ha escrit: path, init u on its own won't work. I would suggest this strategy: 1) Create /run/initctl 2) Symlink /dev/initctl (or /etc/.initctl) to /run/initctl 3) Send SIGUSR1 to init → init reopens using the old path, but is redirected to use /run/initctl 4) Wait for that action to complete 5) Run init q to re-exec init. The new init will use the new paths 6) Delete the no-longer-needed /dev/initctl (or /etc/.initctl). Seems good, but I dislike step 4, as it opens the door for race conditions. Can't we just remove steps 4 and 5? I think everything would work without them. If we don't do that, then we are left running the old /sbin/init binary, which is an important part of the upgrade. If there's a way to detect a listener on a pipe, we could do that. Or if telinit/init return an error code, we can loop until it succeeds. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
El 8 de gener de 2012 16:20, Roger Leigh rle...@codelibre.net ha escrit: If we don't do that, then we are left running the old /sbin/init binary, which is an important part of the upgrade. Only until reboot. A reboot is necessary for the upgrade anyway (needed by kernel). Or if telinit/init return an error code, we can loop until it succeeds. That could work, yes. If init didn't act upon SIGUSR1 yet, its initctl handle is for a node that no longer exists in the file system. Then the only way for it to receive commands is to re-open $OLDINITCTL which is now a symlink. Btw, isn't step 6 a pre-requisite for step 2? -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
On Sun, Jan 08, 2012 at 04:29:43PM +0100, Robert Millan wrote: El 8 de gener de 2012 16:20, Roger Leigh rle...@codelibre.net ha escrit: If we don't do that, then we are left running the old /sbin/init binary, which is an important part of the upgrade. Only until reboot. A reboot is necessary for the upgrade anyway (needed by kernel). Or if telinit/init return an error code, we can loop until it succeeds. That could work, yes. If init didn't act upon SIGUSR1 yet, its initctl handle is for a node that no longer exists in the file system. Then the only way for it to receive commands is to re-open $OLDINITCTL which is now a symlink. Btw, isn't step 6 a pre-requisite for step 2? No, 2) is replacing with a symlink, while 6) is removing the now unneeded symlink. I noticed that if you mv /dev/initctl /dev/initctl.old, init (I presume) immediately recreates /dev/initctl. The following sequence appears to work: # New control channel mkfifo /run/initctl # Symlink to new channel ln -s /run/initctl /dev/initctl.new # Replace existing channel with symlink mv /dev/initctl.new /dev/initctl # Reopen control channel (now /run/initctl) kill -SIGUSR1 1 # Replace init with new version using new paths init u # Delete old path [rm /run/initctl] If /dev/initctl is not open or is invalid, init u exits with an error, so we can loop on this in the postinst to wait until it's reopened. It's pretty quick though, so perhaps loop a fixed number of times and then continue with a warning if not possible, especially since it's not fatal? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
El 8 de gener de 2012 16:47, Roger Leigh rle...@codelibre.net ha escrit: No, 2) is replacing with a symlink, while 6) is removing the now unneeded symlink. I noticed that if you mv /dev/initctl /dev/initctl.old, init (I presume) immediately recreates /dev/initctl. The following sequence appears to work: # New control channel mkfifo /run/initctl # Symlink to new channel ln -s /run/initctl /dev/initctl.new # Replace existing channel with symlink mv /dev/initctl.new /dev/initctl # Reopen control channel (now /run/initctl) kill -SIGUSR1 1 # Replace init with new version using new paths init u # Delete old path [rm /run/initctl] If /dev/initctl is not open or is invalid, init u exits with an error, so we can loop on this in the postinst to wait until it's reopened. It's pretty quick though, so perhaps loop a fixed number of times and then continue with a warning if not possible, especially since it's not fatal? Sounds good. Btw, please remember not to hardcode /dev/initctl since the old path is kernel-specific. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
On Sun, Jan 08, 2012 at 03:01:57PM +0100, Robert Millan wrote: El 8 de gener de 2012 15:00, Robert Millan r...@debian.org ha escrit: El 8 de gener de 2012 14:56, Roger Leigh rle...@codelibre.net ha escrit: The postinst currently calls init u, but I think that's problematic-- it would call the new binary using the new path. On the contrary, isn't this precisely what we wanted? No symlink needed then. Uhm, not sure if I understood correctly what init u does. Anyway, I'd propose this approach: - Create a new fifo in new path (no symlink). - Install new binaries (both sides) which use the new path. - Force init re-exec using a signal. Please could you try the package at http://people.debian.org/~rleigh/sysvinit/sysvinit_2.88dsf-19.dsc Let me know if the postinst logic is acceptable to you. It works for me, and the increasing delay should work for all but the slowest/loaded systems. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638019: /run/initctl
user rle...@debian.org usertag 638019 run-transition thanks I didn't notice this was actually a Release Goal [1]. Tagging appropiately. I should note that the patch I sent has an unwanted side-effect: unability to send messages to init until after first reboot, which means first reboot can't be done cleanly. Maybe clients can be modified to attempt old path first then try with /run/initctl (or vice-versa), or update scripts could play some kind of symlink trick. I haven't had time to resolve this however. [1] http://wiki.debian.org/ReleaseGoals/RunDirectory -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
