Re: Request for testing: /run and initscripts
Roger, I could not find any references to debootstrap installations with the new /run setup. How is debootstrap - and any other program installing Debian - supposed to handle /run, esp. with the initscripts postinst detecting chroots and it not bringing in the preferred setup? Thanks, -ch (Please keep me CC'ed.) signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Tue, May 10, 2011 at 11:43:42PM +0200, chris h wrote: I could not find any references to debootstrap installations with the new /run setup. How is debootstrap - and any other program installing Debian - supposed to handle /run, esp. with the initscripts postinst detecting chroots and it not bringing in the preferred setup? Currently, it does require initscripts to be installed, and it only sets up symlinks rather than moving things around (which isn't safe). Once we have initscripts in unstable (should be fairly soon now, the needed initramfs-tools changes are now in git), base-files can then start to provide /run. At this point a debootstrap will result in a /run directory being created, rather than a symlink. We can probably also get base-files to create the /var/run and /var/lock symlinks so that you'll get a correct system when you debootstrap. So this will work--it'll just take a bit of careful planning so all the bits fall into place in the correct order. 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. signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Thu, Apr 14, 2011 at 08:19:38PM +0100, Roger Leigh wrote: On Thu, Apr 14, 2011 at 11:29:31AM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 10:22:33PM +0100, Roger Leigh wrote: On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote: I have now implemented this (though it's not the default). I would very much appreciate it if anyone could take the time to install the new initscripts and test it out. http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb It breaks down at least on vservers (which can't do mount() calls): find: `var/run': No such file or directory fakerunlevel: open(/var/run/utmp): No such file or directory I've now added support for vservers to the postinst (we treat them like chroots, since they appear not to run rcS, which is probably the root cause of the problems here). The updated packages are at the URIs above; could you possibly give it a try and let me know if it works. guest environment detected: Migrating /var/run to /run mv: cannot move `/var/run' to `/run': Directory not empty Can't move /var/run to /run and replace with symlink; please fix manually. dpkg: error processing initscripts (--install): I think this should be fixed now; could you possibly try again (you'll need a clean vserver environment that hasn't been upgraded before). The updated packages are at the same location as before. I've tried: * a copy of one that has seen no initscripts_2.88dsf-13.3 but was upgraded since sarge * a freshly debootstrapped one Sadly, every time I get: fakerunlevel: open(/var/run/utmp): No such file or directory # ls -al var/ total 32 drwxr-xr-x 11 root root 4096 Apr 15 12:45 . drwxr-xr-x 21 root root 4096 Apr 15 12:44 .. drwxr-xr-x 2 root root 1 Apr 6 20:58 backups drwxr-xr-x 6 root root56 Apr 15 11:41 cache drwxr-xr-x 17 root root 4096 Apr 15 12:38 lib drwxrwsr-x 2 root staff1 Apr 6 20:58 local drwxr-xr-x 5 root root 4096 Apr 15 12:44 log drwxrwsr-x 2 root mail 1 Apr 15 11:40 mail drwxr-xr-x 2 root root 1 Apr 15 11:40 opt drwxr-xr-x 3 root root24 Apr 15 11:40 spool drwxrwxrwt 2 root root 1 Apr 6 20:58 tmp -- indeed, no /var/run, symlinked or not. Output when upgrading was: (Reading database ... 11217 files and directories currently installed.) Preparing to replace initscripts 2.88dsf-13.2 (using initscripts_2.88dsf-13.3_i386.deb) ... Unpacking replacement initscripts ... Setting up initscripts (2.88dsf-13.3) ... Installing new version of config file /etc/init.d/checkfs.sh ... Installing new version of config file /etc/init.d/checkroot.sh ... Installing new version of config file /etc/init.d/mountdevsubfs.sh ... Installing new version of config file /etc/init.d/mountkernfs.sh ... Installing new version of config file /etc/init.d/mtab.sh ... Installing new version of config file /etc/init.d/sendsigs ... Installing new version of config file /etc/init.d/umountfs ... Installing new version of config file /etc/init.d/umountnfs.sh ... Installing new version of config file /etc/default/tmpfs ... guest environment detected: Migrating /var/run to /run guest environment detected: Migrating /var/lock to /run/lock guest environment detected: Not migrating in-use files in /dev/shm to /run/shm Processing triggers for man-db ... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Fri, Apr 15, 2011 at 12:55:20PM +0200, Adam Borowski wrote: On Thu, Apr 14, 2011 at 08:19:38PM +0100, Roger Leigh wrote: I think this should be fixed now; could you possibly try again (you'll need a clean vserver environment that hasn't been upgraded before). The updated packages are at the same location as before. I've tried: * a copy of one that has seen no initscripts_2.88dsf-13.3 but was upgraded since sarge * a freshly debootstrapped one Sadly, every time I get: fakerunlevel: open(/var/run/utmp): No such file or directory guest environment detected: Migrating /var/run to /run guest environment detected: Migrating /var/lock to /run/lock guest environment detected: Not migrating in-use files in /dev/shm to /run/shm Processing triggers for man-db ... This I really don't get. There was no error reported, and we're using this logic: if [ ! -L /var/run ] [ -d /var/run ]; then echo guest environment detected: Migrating /var/run to /run ( # Remove /run first, so all contents get moved rm -fr /run mv /var/run / ln -fs /run /var/run ) || ( echo Can't move /var/run to /run and replace with symlink; please fix manually.; exit 1 ) fi If the symlink creation failed, you should have got an error message. I tested this in a chroot environment, and it worked fine. Does anyone have any clue? Is the logic not right in the subshell or something? Thanks, 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. signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Fri, 15 Apr 2011, Roger Leigh wrote: This I really don't get. There was no error reported, and we're using this logic: if [ ! -L /var/run ] [ -d /var/run ]; then echo guest environment detected: Migrating /var/run to /run ( # Remove /run first, so all contents get moved rm -fr /run mv /var/run / ln -fs /run /var/run ) || ( echo Can't move /var/run to /run and replace with symlink; please fix manually.; exit 1 ) fi So, er, /var/run is going to be missing for an appreciable length of time. Is this acceptable? Also, if /var is not on the / fs mv is going to fall back to a recursive copy, which: - races with anything using /var/run - breaks named pipes and sockets[0] - other badness (I'll assume there's more than immediately comes to mind ;) [0] mv unlinks then mknods fifos and sockets, but cannot restore a link from the new inode to any processes which already have an fd open I'm assuming this is the degenerate fallback case when you can't use mount --bind, but I think we can still do better. Why not ln /var/run /run in this case and switch the symlink and actual location after the next boot? If some guest environments skip all of rcS then I'd hope they make some other provisions for at boot cleanup and other tasks. Otherwise the best we can do is document these changes in the release notes as something the local admin needs to take care of. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1104151315410.30...@pandora.retrosnub.co.uk
Re: Request for testing: /run and initscripts
On Fri, Apr 15, 2011 at 01:38:34PM +0100, Edward Allcutt wrote: On Fri, 15 Apr 2011, Roger Leigh wrote: This I really don't get. There was no error reported, and we're using this logic: if [ ! -L /var/run ] [ -d /var/run ]; then echo guest environment detected: Migrating /var/run to /run ( # Remove /run first, so all contents get moved rm -fr /run mv /var/run / ln -fs /run /var/run ) || ( echo Can't move /var/run to /run and replace with symlink; please fix manually.; exit 1 ) fi So, er, /var/run is going to be missing for an appreciable length of time. Is this acceptable? Also, if /var is not on the / fs mv is going to fall back to a recursive copy, which: - races with anything using /var/run - breaks named pipes and sockets[0] - other badness (I'll assume there's more than immediately comes to mind ;) This is correct. But as mentioned below, this is a fallback, not the default. The default bind mount behaviour is race-free and entirely transparent. [0] mv unlinks then mknods fifos and sockets, but cannot restore a link from the new inode to any processes which already have an fd open I'm assuming this is the degenerate fallback case when you can't use mount --bind, but I think we can still do better. Why not ln /var/run /run in this case and switch the symlink and actual location after the next boot? Your assumption is correct in that this is a fallback. This is the special case for chroots, also co-opted for vservers, which don't boot per se, and don't run the rcS scripts. The consequence of this is that we can't do any setup at boot time; the chances are that no filesystems will be mounted at all, and if there are, we don't have any control over that process. This means that the migration in postinst is unfortunately a best effort; I'd like to make it more reliable if at all possible. The assumption is that there won't be anything running having open files in /var/(run|lock)--unlike for a normal host, we can't do any bind mounts or other clever stuff, because they'll be lost on restart, and hence the new paths will never be set up again, causing breakage. An alternative could be to just copy the contents, but we really do need the symlinks in place or else programs can't transition to the new paths transparently as on normal systems. If some guest environments skip all of rcS then I'd hope they make some other provisions for at boot cleanup and other tasks. Otherwise the best we can do is document these changes in the release notes as something the local admin needs to take care of. For regular chroot environments, e.g. as used on buildds, sbuild, schroot, etc., these directories won't normally be used. If you're running services inside a chroot environment, you'll need to stop them prior to upgrading. This isn't a new requirement though--chroots have all sorts of limitations such as this, and having a 100% reliable upgrade path in situations like this is hard to achieve. As mentioned in another post, the above shell script can probably be made more reliable on failure, but it's likely that some chroots will need the admin to move stuff by hand if it fails. 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. signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Fri, 15 Apr 2011, Roger Leigh wrote: On Fri, Apr 15, 2011 at 01:38:34PM +0100, Edward Allcutt wrote: Your assumption is correct in that this is a fallback. This is the special case for chroots, also co-opted for vservers, which don't boot per se, and don't run the rcS scripts. The consequence of this is that we can't do any setup at boot time; the chances are that no filesystems will be mounted at all, and if there are, we don't have any control over that process. This means that the migration in postinst is unfortunately a best effort; I'd like to make it more reliable if at all possible. In the case described, with a writable / and no tmpfs, what is the downside to my suggestion? /run would remain linked to /var/run forevermore[0] if the boottime switcheroo does not happen, but that doesn't seem so terrible. Both /run and /var/run will remain writable and effectively the same location, which points to the other isn't terribly important in the short term. [0] or until the admin prods it as specified in the release notes. The assumption is that there won't be anything running having open files in /var/(run|lock) I think that's an assumption that will fail in some cases and since we can avoid it we should do so. I have run things like databases and asterisk in chroots and would vastly prefer running upgrades to not be broken. An alternative could be to just copy the contents, but we really do need the symlinks in place or else programs can't transition to the new paths transparently as on normal systems. Copying the contents is the main thing I'm objecting to. I'm proposing creating symlinks which do allow a transparent transition and leaving it to the admin to switch the links around at a convenient time if rc scripts are skipped. I agree that unusual custom chroot environments can't always be handled fully automatically. Where I disagree is whether we should make assumptions which would break running systems rather than simply giving the admin the details needed to adapt the custom environment at a time convenient to them.[1] [1] I'm going to guess we'll assume they've taken care of such things before upgrading to wheezy+1. That seems like a much looser and safer assumption. Thank you very much for your time and effort on moving to /run in Debian. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1104151503390.30...@pandora.retrosnub.co.uk
Re: Request for testing: /run and initscripts
Edward Allcutt edw...@allcutt.me.uk writes: On Fri, 15 Apr 2011, Roger Leigh wrote: This I really don't get. There was no error reported, and we're using this logic: if [ ! -L /var/run ] [ -d /var/run ]; then echo guest environment detected: Migrating /var/run to /run ( # Remove /run first, so all contents get moved rm -fr /run mv /var/run / ln -fs /run /var/run ) || ( echo Can't move /var/run to /run and replace with symlink; please fix manually.; exit 1 ) fi So, er, /var/run is going to be missing for an appreciable length of time. Is appreciable length of time? The time to do an atomic mv (not the copy fallback) followed by ln should be unnoticable and suitable hard to hit by any running program. this acceptable? Also, if /var is not on the / fs mv is going to fall back to a recursive copy, which: - races with anything using /var/run - breaks named pipes and sockets[0] - other badness (I'll assume there's more than immediately comes to mind ;) The copying fallback also break any open files. [0] mv unlinks then mknods fifos and sockets, but cannot restore a link from the new inode to any processes which already have an fd open I'm assuming this is the degenerate fallback case when you can't use mount --bind, but I think we can still do better. Why not ln /var/run /run in this case and switch the symlink and actual location after the next boot? If some guest environments skip all of rcS then I'd hope they make some other provisions for at boot cleanup and other tasks. Otherwise the best we can do is document these changes in the release notes as something the local admin needs to take care of. This was specifically about vserver testing where rcS scripts aren't executed. We are indeed in a fallback case, one where we can't use boot scripts. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipufk1k2.fsf@frosties.localnet
Re: Request for testing: /run and initscripts
On Fri, Apr 15, 2011 at 03:26:59PM +0100, Edward Allcutt wrote: On Fri, 15 Apr 2011, Roger Leigh wrote: On Fri, Apr 15, 2011 at 01:38:34PM +0100, Edward Allcutt wrote: Your assumption is correct in that this is a fallback. This is the special case for chroots, also co-opted for vservers, which don't boot per se, and don't run the rcS scripts. The consequence of this is that we can't do any setup at boot time; the chances are that no filesystems will be mounted at all, and if there are, we don't have any control over that process. This means that the migration in postinst is unfortunately a best effort; I'd like to make it more reliable if at all possible. In the case described, with a writable / and no tmpfs, what is the downside to my suggestion? /run would remain linked to /var/run forevermore[0] if the boottime switcheroo does not happen, but that doesn't seem so terrible. Both /run and /var/run will remain writable and effectively the same location, which points to the other isn't terribly important in the short term. ... Copying the contents is the main thing I'm objecting to. I'm proposing creating symlinks which do allow a transparent transition and leaving it to the admin to switch the links around at a convenient time if rc scripts are skipped. Thanks for making me reconsider the approach we were taking with chroots. This is a much better strategy. This does make a lot of sense in a chroot environment, and I've now switched to symlinking /run → /var/run /run/lock (/var/run/lock) → /var/lock /run/shm (/var/run/shm) → /dev/shm This ensures no files are moved during the upgrade, and files are accessible via the old and new paths. Unlike for a host system, we don't start using the new locations as the default, and symlink to them from the old locations. We do it the other way around. If the admin wishes to complete the transition, they will need to move the contents and create the old→new symlinks by hand. This also solves the vserver issues, since /var/run and /var/lock will remain directories. But that's a vserver bug needing addressing separately, since at some point in the (distant) future (= wheezy+1) we will want to ship /var/run and /var/lock as symlinks, and (longer term) remove them entirely perhaps. So with this change in place, upgrading chroots/vservers is as reliable as for hosts. 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. signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Wed, Apr 13, 2011 at 10:22:33PM +0100, Roger Leigh wrote: On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote: I have now implemented this (though it's not the default). I would very much appreciate it if anyone could take the time to install the new initscripts and test it out. http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb It breaks down at least on vservers (which can't do mount() calls): find: `var/run': No such file or directory fakerunlevel: open(/var/run/utmp): No such file or directory I've now added support for vservers to the postinst (we treat them like chroots, since they appear not to run rcS, which is probably the root cause of the problems here). The updated packages are at the URIs above; could you possibly give it a try and let me know if it works. guest environment detected: Migrating /var/run to /run mv: cannot move `/var/run' to `/run': Directory not empty Can't move /var/run to /run and replace with symlink; please fix manually. dpkg: error processing initscripts (--install): subprocess installed post-installation script returned error exit status 1 Processing triggers for man-db ... Errors were encountered while processing: initscripts After manually moving /var/run and putting a symlink there: [~]# vserver durthang start fakerunlevel: open(/var/run/utmp): No such file or directory Failed to start vserver 'durthang' -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Thu, Apr 14, 2011 at 11:29:31AM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 10:22:33PM +0100, Roger Leigh wrote: On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote: I have now implemented this (though it's not the default). I would very much appreciate it if anyone could take the time to install the new initscripts and test it out. http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb It breaks down at least on vservers (which can't do mount() calls): find: `var/run': No such file or directory fakerunlevel: open(/var/run/utmp): No such file or directory I've now added support for vservers to the postinst (we treat them like chroots, since they appear not to run rcS, which is probably the root cause of the problems here). The updated packages are at the URIs above; could you possibly give it a try and let me know if it works. guest environment detected: Migrating /var/run to /run mv: cannot move `/var/run' to `/run': Directory not empty Can't move /var/run to /run and replace with symlink; please fix manually. dpkg: error processing initscripts (--install): I think this should be fixed now; could you possibly try again (you'll need a clean vserver environment that hasn't been upgraded before). The updated packages are at the same location as before. Thanks, 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. signature.asc Description: Digital signature
Request for testing: /run and initscripts
On Wed, Apr 13, 2011 at 01:23:04PM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 10:51:50AM +0100, Philip Hands wrote: On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl bi...@debian.org wrote: I don't think symlinking /tmp to /run would be a good idea, as one could fill up /tmp (accidentaly) pretty quick. If we want to make / ro, then a separate tmpfs for /tmp looks like a better idea to me. While were about this, for installs where the users select multiple partitions we currently create a separate /tmp partition. This strikes me as suboptimal, since one could use the disk space allocated to /tmp as extra swap and then allocate a tmpfs of that size to be mounted on /tmp with no effect other than allowing the system to have access to more swap than it would have otherwise had (of course, that's probably more than it needs, so instead you could just save some disk space that would otherwise be left generally unused by overloading the swap usage with /tmp usage. Therefore, in the multi-partition setup, I think we should also default to having /tmp on tmpfs. Sounds like a great idea. I'd extend it to any setups with a swap. Tmpfs is a lot faster than regular filesystems: it doesn't have to care about preserving the data's integrity after a crash and thus has no barriers, journaling, fsync(). When there's plenty of unused memory, the data will not ever touch the disk, too -- gracefully getting written out when there is a better use for memory it takes. Since most files in /tmp/ are very short lived, it's a good optimization. I have now implemented this (though it's not the default). I would very much appreciate it if anyone could take the time to install the new initscripts and test it out. http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb Note that it is safe to test these out on live systems; I've installed it on my amd64 and powerpc machines, and not had any issues. I did notice an unclean umount of /var in one case, but I think this was due to messing around with mount --move which messes up /etc/mtab when moving recursively (/run/lock probably didn't get unmounted). I've not seen that on any other systems. So, by default, you get (separate tmpfs mounts): /run /run/shm /lib/init/rw (RAMLOCK=no, RAMSHM=yes, RAMTMP=no) For additional safety and security, it's possible to mount everything as separate tmpfs filesystems: /run /run/shm /run/lock /lib/init/rw /tmp (RAMLOCK=yes, RAMSHM=yes, RAMTMP=yes). This lets one have separate size limits and mount modes for each mount. Alternatively, it's possible to have everything on a single /run tmpfs, including /tmp (excluding /lib/init/rw, which will be removed soon): /run /lib/init/rw /tmp → /run/tmp (RAMLOCK=no, RAMSHM=no, RAMTMP=no). Note that /tmp was symlinked to /run/tmp prior to restarting, and /run/tmp was created by the init scripts (mountkernfs). The symlink needs creating by hand should you wish to do this. Having /tmp as a symlink can be used whatever the setting of RAMTMP, so you could have a tmpfs mounted on /run/tmp if you chose. In all these cases, these links were automatically created: /dev/shm → /run/shm /var/run → /run /var/lock → /run/lock The default size and permissions were set as proposed earlier in this thread; there's still time to adjust or remove those depending upon what the general consensus is. We could also make not mounting /run/shm the default, so that it's shared with /run by default; users who need a dedicated large /run/shm could then enable this at their discretion using RAMSHM and SHM_SIZE. I would be very grateful to anyone who can take the time to install the new initscripts and try it out. It should set up bind mounts of /var/run, /var/lock and /dev/shm to their locations in /run on installation, and then set up the tmpfs filesystems properly and do the conversion to symlinks on reboot. Note that I did discuss doing this migration all in postinst using mount --move with mbiebl, but it's unfortuntately linux-specific and has some race conditions between moving and setting up the symlinks (which may or may not be acceptable). This patch errs on the side of caution and ensures that the directories being moved are available at all times, and that the code works on all architectures. Also note that the move of /dev/shm to /run/shm might require the selinux stuff tweaking. This might require a change in one of the selinux packages. But I know little about selinux. One oddity I noticed was that /etc/default/rcS is not a conffile, making it difficult to add new options on upgrade since it's only copied once on initial install. Does anyone know why this is the case, and would it be a problem if I made it into a conffile in order to add the new RAMSHM and RAMTMP options (and remove RAMRUN)? I've worked around this by setting defaults if unset in
Re: Request for testing: /run and initscripts
On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote: I have now implemented this (though it's not the default). I would very much appreciate it if anyone could take the time to install the new initscripts and test it out. http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb It breaks down at least on vservers (which can't do mount() calls): find: `var/run': No such file or directory fakerunlevel: open(/var/run/utmp): No such file or directory -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote: I have now implemented this (though it's not the default). I would very much appreciate it if anyone could take the time to install the new initscripts and test it out. http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb It breaks down at least on vservers (which can't do mount() calls): find: `var/run': No such file or directory fakerunlevel: open(/var/run/utmp): No such file or directory When is this, in postinst or init scripts? We have logic in postinst to detect chroot environments and not do any mounting; could we add a similar check for vservers? Thanks, 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. signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Wed, Apr 13, 2011 at 02:24:30PM +0100, Roger Leigh wrote: On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote: I have now implemented this (though it's not the default). I would very much appreciate it if anyone could take the time to install the new initscripts and test it out. http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb It breaks down at least on vservers (which can't do mount() calls): find: `var/run': No such file or directory fakerunlevel: open(/var/run/utmp): No such file or directory When is this, in postinst or init scripts? We have logic in postinst to detect chroot environments and not do any mounting; could we add a similar check for vservers? postinst reported success. This error was upon trying to [re]start the vserver afterwards, not sure where exactly it comes from. You might want to ask someone who deals with LXC to test it as well, as it has a different approach to mounting filesystems inside the guest. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Wed, Apr 13, 2011 at 02:24:30PM +0100, Roger Leigh wrote: On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote: find: `var/run': No such file or directory fakerunlevel: open(/var/run/utmp): No such file or directory When is this, in postinst or init scripts? We have logic in postinst to detect chroot environments and not do any mounting; could we add a similar check for vservers? No. You have to handle errors in mouting in all cases. Even the init script may fail there. Bastian -- Fascinating is a word I use for the unexpected. -- Spock, The Squire of Gothos, stardate 2124.5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110413133936.ga31...@wavehammer.waldi.eu.org
Re: Request for testing: /run and initscripts
On Wed, Apr 13, 2011 at 03:35:24PM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 02:24:30PM +0100, Roger Leigh wrote: On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote: I have now implemented this (though it's not the default). I would very much appreciate it if anyone could take the time to install the new initscripts and test it out. http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb It breaks down at least on vservers (which can't do mount() calls): find: `var/run': No such file or directory fakerunlevel: open(/var/run/utmp): No such file or directory When is this, in postinst or init scripts? We have logic in postinst to detect chroot environments and not do any mounting; could we add a similar check for vservers? postinst reported success. This error was upon trying to [re]start the vserver afterwards, not sure where exactly it comes from. Not knowing anything about vservers, do they normally run the standard rcS init scripts? While this patch does change some mounts to new locations, it's pretty much doing the same thing as before. If /dev/shm and /lib/init/rw aren't mounted, it looks like they are not run. After this failure, does /var/run exist? Is it a directory or symlink? What's mounted there or what does it point to? Is that location also valid? When the postinst ran, did it set up bind mounts, or did it run the chroot setup only? If vservers never run the rcS scripts, we need to ensure that the package runs the same postinst codepaths as for chroots. Is it possible to determine if we are running in a vserver enviroment in the postinst? You might want to ask someone who deals with LXC to test it as well, as it has a different approach to mounting filesystems inside the guest. Looks a bit more comprehensive, and you have the choice of running the native init. We would need to know if rcS will be run or not when running the postinst. Comments from anyone using lxc with Debian would be most helpful. 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. signature.asc Description: Digital signature
Re: Request for testing: /run and initscripts
On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote: On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote: I have now implemented this (though it's not the default). I would very much appreciate it if anyone could take the time to install the new initscripts and test it out. http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb It breaks down at least on vservers (which can't do mount() calls): find: `var/run': No such file or directory fakerunlevel: open(/var/run/utmp): No such file or directory I've now added support for vservers to the postinst (we treat them like chroots, since they appear not to run rcS, which is probably the root cause of the problems here). The updated packages are at the URIs above; could you possibly give it a try and let me know if it works. The same applies to lxc; if anyone uses it, I'd appreciate feedback. I don't have any direct knowledge, so I am reliant upon users for testing. The same applies to GNU/Hurd. Thanks, 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. signature.asc Description: Digital signature
