Bug#335309: hdparm: Please add LSB formatted dependency info in init.d script
This one time, at band camp, Petter Reinholdtsen said: Package: hdparm Version: 6.1-7 Severity: wishlist To be able to check boot script order, and also to be able to start boot scripts in parallel, it is important to know the dependencies of the various boot scripts. The Linux Software Base specifies a init.d header file format useful for this purpose, and adding such header to the init.d scripts would make it possible for me to use this information to check the current sequence and speed up the debian boot. URL:http://refspecs.freestandards.org/LSB_2.1.0/LSB-generic/LSB-generic/initscrcomconv.html documents the LSB header format. Some debian notes are available from URL:http://wiki.debian.org/?LSBInitScripts. Here is a proposed dependency header to document the dependencies of hdparm. It is slightly tested using the insserv package and the new parallell booting support in sysvinit. ### BEGIN INIT INFO # Provides: hdparm # Required-Start:mountvirtfs # Required-Stop: # Default-Start: S 1 2 3 4 5 # Default-Stop: 0 6 ### END INIT INFO Default-Start should really only be S, except that if a device node is created by udev or something later, it will run again for that device node. I do not know if that makes a difference in this setup, though. Also, it seems that hdparm should start after udev and/or coldplug has created the real device node for the root fs, if they are present. So, from my reading of things, this gives us: ### BEGIN INIT INFO # Provides: hdparm # Required-Start:mountvirtfs # Should-Start: udev coldplug # Required-Stop: # Default-Start: S # Default-Stop: 0 6 ### END INIT INFO Does that look right to you? Does coldplug even use an init script (I don't know, having given up on md maintained packages for now)? Take care, and thanks, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#335309: hdparm: Please add LSB formatted dependency info in init.d script
[Stephen Gran] Default-Start should really only be S, except that if a device node is created by udev or something later, it will run again for that device node. I do not know if that makes a difference in this setup, though. You probably know best. It does not make much difference in this context, as the bootscripts are only executed in the new runlevel if it was not executed in the previous one, and moving from S to 2 (debian default) would make sure it only is executed once. Does that look right to you? Does coldplug even use an init script (I don't know, having given up on md maintained packages for now)? Looks good to me, but the added should-start might give loops. I'm not sure if udev or coldplug should a dependency leading up to hdparm. I have no idea if coldplug have an init.d script, either. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335309: hdparm: Please add LSB formatted dependency info in init.d script
This one time, at band camp, Petter Reinholdtsen said: [Stephen Gran] Default-Start should really only be S, except that if a device node is created by udev or something later, it will run again for that device node. I do not know if that makes a difference in this setup, though. You probably know best. It does not make much difference in this context, as the bootscripts are only executed in the new runlevel if it was not executed in the previous one, and moving from S to 2 (debian default) would make sure it only is executed once. I see. Well, I always feel it's better to be explicit rather than relying on expected behavior that, when it changes for some other reason, causes random breakage, so I'll leave it with just S for now. Does that look right to you? Does coldplug even use an init script (I don't know, having given up on md maintained packages for now)? Looks good to me, but the added should-start might give loops. I'm not sure if udev or coldplug should a dependency leading up to hdparm. I have no idea if coldplug have an init.d script, either. :) Hmm, time to get the source for it, then. They really should not be relying on hdparm in any way (nothing should, really - it's merely a tuner for when the kernel can't get it right by default), so hopefully loops won't be a problem. Thanks again, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#335309: hdparm: Please add LSB formatted dependency info in init.d script
This one time, at band camp, Petter Reinholdtsen said: [Stephen Gran] Default-Start should really only be S, except that if a device node is created by udev or something later, it will run again for that device node. I do not know if that makes a difference in this setup, though. You probably know best. It does not make much difference in this context, as the bootscripts are only executed in the new runlevel if it was not executed in the previous one, and moving from S to 2 (debian default) would make sure it only is executed once. Does that look right to you? Does coldplug even use an init script (I don't know, having given up on md maintained packages for now)? Looks good to me, but the added should-start might give loops. I'm not sure if udev or coldplug should a dependency leading up to hdparm. I have no idea if coldplug have an init.d script, either. :) So, after talking it over with md on IRC, it looks like coldplug does not have an init script, and there is no danger of him depending on hdparm. So I will add the lsb header I mentioned, but minus the coldplug bit. Now, one thing that has been bothering me - is there a facility in these scripts to sya, 'wait until all scripts of type foo are done to start, if present'? In other words, something like a Should-Start-Group: with the other scripts useing a Member-Of: rather than a Provides: header? This would be helpful for, for instance, sendmail, where you want it to wait for all milters to start - sendmail's init script could wait on group milter, and then all the milters could declare themselves part of milter, and be started in parallel. I only see a single instance, meaning sendmail would have to have a Should-Start: line for every single thing it might use, which seems definitely unwieldy. It seems in the current arrangement, a single milter startup provides milter (for instance) and then sendmail can start, which is wrong. This is getting OT for the bug report, but I thought I'd ask, as this sort of thing is going to come up for clamav. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#335309: hdparm: Please add LSB formatted dependency info in init.d script
[Stephen Gran] Now, one thing that has been bothering me - is there a facility in these scripts to sya, 'wait until all scripts of type foo are done to start, if present'? In other words, something like a Should-Start-Group: with the other scripts useing a Member-Of: rather than a Provides: header? There is some facility for this, using the $facility notation. But it is not very good for this. My proposal to solve this, is some kind of 'before' statement, but it is not standardized nor implemented anywere. This would be helpful for, for instance, sendmail, where you want it to wait for all milters to start - sendmail's init script could wait on group milter, and then all the milters could declare themselves part of milter, and be started in parallel. Here the milters (no idea what a milter is. :) would express that they want to start before sendmail, and the script ordering system would try to make sure this happen. :) But as I said, there is no support for this at the moment. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335309: hdparm: Please add LSB formatted dependency info in init.d script
This one time, at band camp, Petter Reinholdtsen said: [Stephen Gran] Now, one thing that has been bothering me - is there a facility in these scripts to sya, 'wait until all scripts of type foo are done to start, if present'? In other words, something like a Should-Start-Group: with the other scripts useing a Member-Of: rather than a Provides: header? There is some facility for this, using the $facility notation. But it is not very good for this. My reading of the proposal was that when a single thing providing $facility comes up, the launcher interprets that to mean that $facility is available - exactly what I am trying to address. My proposal to solve this, is some kind of 'before' statement, but it is not standardized nor implemented anywere. That's not unreasonable, but since we already have other classful containers for depending objects (all objects waiting on $network, for instance), it seems easier to just abstract that to provide classful containers for providing objects as well. Of course, I am saying this without looking at a whit of code, so I may just be speaking out of my ass, but that's not uncommon :) This would be helpful for, for instance, sendmail, where you want it to wait for all milters to start - sendmail's init script could wait on group milter, and then all the milters could declare themselves part of milter, and be started in parallel. Here the milters (no idea what a milter is. :) would express that they want to start before sendmail, and the script ordering system would try to make sure this happen. :) A milter is a MailfILTER for sendmail - the particular problem here is that sendmail needs them running before it starts processing mail, as it will immediately try to communicate with them and fail. But this was a generalization of a more abstract problem, I think - I can think of many classes of things that may have multiple subparts, and all the subparts should be up. For instance, $time might actually involve hwctosys, ntpdate and ntp-server all coming up, so that an application that is very picky about timing doesn't puke when the system clock suddenly jumps. But as I said, there is no support for this at the moment. Oh well. Thanks for the discussion, though. Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#335309: hdparm: Please add LSB formatted dependency info in init.d script
Package: hdparm Version: 6.1-7 Severity: wishlist To be able to check boot script order, and also to be able to start boot scripts in parallel, it is important to know the dependencies of the various boot scripts. The Linux Software Base specifies a init.d header file format useful for this purpose, and adding such header to the init.d scripts would make it possible for me to use this information to check the current sequence and speed up the debian boot. URL:http://refspecs.freestandards.org/LSB_2.1.0/LSB-generic/LSB-generic/initscrcomconv.html documents the LSB header format. Some debian notes are available from URL:http://wiki.debian.org/?LSBInitScripts. Here is a proposed dependency header to document the dependencies of hdparm. It is slightly tested using the insserv package and the new parallell booting support in sysvinit. ### BEGIN INIT INFO # Provides: hdparm # Required-Start:mountvirtfs # Required-Stop: # Default-Start: S 1 2 3 4 5 # Default-Stop: 0 6 ### END INIT INFO -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
