Re: Dependency-based boot ordering and sysvinit in unstable
Despite all the cruft that I had sitting there (most of it doing nothing at all, thankfully), it worked like a charm!! And what a fast startup. Well done and beyond any expectations :-) -- 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/201206281701.06346.d_ba...@012.net.il
Re: Dependency-based boot ordering and sysvinit in unstable
severity 678231 serious severity 676473 serious forgemerge 676463 678231 676473 tags 676463 + pending thanks On Thu, Jun 07, 2012 at 09:31:47PM +0100, Roger Leigh wrote: Hi, If you're using unstable and you're using static boot ordering with sysv-rc, you might have run into #676463/#676520. We've been using dynamic dependency-based boot ordering by default for quite some time now. However, if you had a lenny (or earlier) system, prior to sysv-rc 2.88dsf-23, users had a choice between opting to remain using the old static legacy boot ordering, or to enable dynamic dependency-based boot ordering. In 2.88dsf-23, the question is removed, and dynamic boot ordering will be enabled on all systems. For the majority of users, this won't cause any problems at all. However, if you have any lingering scripts without any LSB headers, you'll need to fix them up or remove them to allow dynamic boot ordering to be enabled. This is obviously not too desirable, since it requires fixing things up by hand. But it doesn't break anything either (other than requiring you to fix things to continue--the boot ordering will be unaffected until the migration can proceed). Ideally, we would be able to skip the sanity checks and just enable it anyway, with the non-LSB scripts getting ordered after all the LSB scripts. This should satisfy the (absent) dependencies in all but the most insane of cases. But this does require testing carefully, which is why it's not done at the present time. The packages at http://people.debian.org/~rleigh/sysvinit/ remove all the old sanity checks and permit insserv to run when scripts without LSB headers are present. The scripts get ordered at the end of $all. i.e. they are run after all scripts with LSB headers, but before rc.local and other scripts that require $all to be run before them. This should be safe to do in all cases, with the exception being any custom scripts which are ordered in a specific place in the runlevel. These will now most likely get run later than previously. However, running after all system-provided services are started will usually be the correct thing to do. This will only cause problems if the script must start strictly before a particular service starts. In this situation, you'll need to add an LSB header describing the specific dependencies. I'd be grateful for any testing and feedback of the above prerelease packages before they get uploaded to unstable. Unless there are any major objections to this change, I'd like to upload this later in the week. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120627073852.gh9...@codelibre.net
Re: Dependency-based boot ordering and sysvinit in unstable
Roger Leigh dixit: However, if you have any lingering scripts without any LSB headers, you'll need to fix them up or remove them to allow dynamic boot ordering to be enabled. This is obviously not too desirable, since sudo apt-get --purge install file-rc insserv- bye //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml -- 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/pine.bsm.4.64l.1206101408510.16...@herc.mirbsd.org
Re: Dependency-based boot ordering and sysvinit in unstable
[Thorsten Glaser] Roger Leigh dixit: However, if you have any lingering scripts without any LSB headers, you'll need to fix them up or remove them to allow dynamic boot ordering to be enabled. This is obviously not too desirable, since sudo apt-get --purge install file-rc insserv- Good reply, and good short term solution! :) Now if only everyone else in Debian would follow your example, perhaps the old and obsolete static init.d script ordering will become maintained again. URL: http://qa.debian.org/popcon.php?package=file-rc show 0.18% of the population do so already, and there is an upward trend, so it might even lead to success. -- Happy hacking Petter Reinholdtsen One of the people who brought you dependency based boot sequencing -- 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/2flfwa388cf@login2.uio.no
Dependency-based boot ordering and sysvinit in unstable
Hi, If you're using unstable and you're using static boot ordering with sysv-rc, you might have run into #676463/#676520. We've been using dynamic dependency-based boot ordering by default for quite some time now. However, if you had a lenny (or earlier) system, prior to sysv-rc 2.88dsf-23, users had a choice between opting to remain using the old static legacy boot ordering, or to enable dynamic dependency-based boot ordering. In 2.88dsf-23, the question is removed, and dynamic boot ordering will be enabled on all systems. For the majority of users, this won't cause any problems at all. However, if you have any lingering scripts without any LSB headers, you'll need to fix them up or remove them to allow dynamic boot ordering to be enabled. This is obviously not too desirable, since it requires fixing things up by hand. But it doesn't break anything either (other than requiring you to fix things to continue--the boot ordering will be unaffected until the migration can proceed). Ideally, we would be able to skip the sanity checks and just enable it anyway, with the non-LSB scripts getting ordered after all the LSB scripts. This should satisfy the (absent) dependencies in all but the most insane of cases. But this does require testing carefully, which is why it's not done at the present time [it wasn't supposed to leave experimental until this was done, but the competing demands of fixing /tmp and other things such as upstart integration meant that it did, so apologies for that]. I'm away for the next 10 days, but I will be looking into this as soon as I get back. In the meantime, if anyone would like to test the safety of removing the sanity check, that would be very useful. The reason for making this change is that packages provide both LSB dependency information, and they also have to separately provide static ordering information when running update-rc.d. However, now the vast majority of systems use dynamic ordering, the static ordering is bitrotting. It's not tested properly, and it will only get worse. Rather than let the quality of the static ordering decline until it results in inevitable breakage, requiring all systems to use dynamic ordering means that all systems will be using the same, sane LSB dependencies, making booting rather more robust, and removing the requirement for maintainers to invent some fictional static order, which isn't being tested by them to ensure it's correct in any case. All the other init systems use dependency-based ordering, and this additionally makes migration to other init systems easier given their use of LSB dependencies for compatibility. The only exception is perhaps file-rc, and this should probably be using insserv to order the scripts even if it doesn't use startpar to run them in parallel, so that it can use LSB dependency ordering as well. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120607203147.gn15...@codelibre.net
