Re: Please all dependency info into your init.d script
On Wed, Oct 24, 2007 at 11:53:54AM +0200, Petter Reinholdtsen wrote: I've created URL:http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot to track the progress of this work. See also URL:http://wiki.debian.org/LSBInitScripts for clues on how to write such header. Please have a look at the URL above and fix your packages. :) Of course, there are also packages not listed here with an init script which needs fixing. At least about me, there are for sure autodir and aolserver4 missing, so I guess the current situation is worst than what it seems :) I guess mass bug filing should be tempted in order to change the current status and warns as many maintainer as possible. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please all dependency info into your init.d script
Here is a small status update on the dependency based init.d script ordering effort. [Petter Reinholdtsen] As you might be aware, there are several bugs in the Debian boot sequence. The bugs affect some combinations of packages, and are some times hard to solve. To solve them once and for all, I want us to switch to a dependency based sequencing of the symlinks in /etc/rc*.d/. I gave a talk about this at Debconf, see URL:https://penta.debconf.org/~joerg/events/21.en.html for the slides and more info. This still holds. For this to work properly, all init.d scripts need to provide dependency information. There is a standard for specifying such dependency information in the LSB, and already 56% of the Debian packages in unstable include the header with dependency information. This message is for the rest of you. I've created URL:http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot to track the progress of this work. See also URL:http://wiki.debian.org/LSBInitScripts for clues on how to write such header. Please have a look at the URL above and fix your packages. :) The amount of packages missing such headers have gone from 44% this summer to 38% at the moment. Most of the packages in a desktop install is already converted, but a few vital ones are still missing. I've used insserv in my sid chroot as a replacement for update-rc.d since this summer, and it seem to work fairly well. There are enough override files to get a correct boot sequence. There is a small bug in insserv when it comes to the shutdown sequence, and I have not been able to figure it out yet. This leads to a slightly wrong halt and reboot sequence, even if the init.d script headers are correct. I hope to find a solution to this issue soon. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please all dependency info into your init.d script
Steve Langasek [EMAIL PROTECTED] writes: On Fri, Jul 13, 2007 at 07:18:17AM +0200, Adrian von Bidder wrote: Hmmm. With slapd, for example, it's certainly possible where one scenario (slapd uses SQL database) directly contradicts another scenario (startup of SQL database uses auth info which is provided by slapd). Not sure how a packager should deal with this. (slapd being used only as an example. Other scenarios for other services are certainly possible.) Well, the OpenLDAP maintainers are likely to deal with this by declaring that a SQL server that needs to read auth info out of LDAP for startup is not supported, and the admin is on their own for making this work. All Debian system accounts should be stored in the nss_files backend, where adduser will put them by default. If your system accounts are in LDAP, you're making your system deliberately fragile, and I see no reason for Debian to make that easier to do. Note that we've had to deal with this problem previously in the OpenLDAP package. I think the most recent example was a DNS server that required the directory be available, when the directory wanted to look things up in DNS. Most of these sorts of problems are best resolved by making one or the other service more robust in the face of such resources not being available at startup. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please all dependency info into your init.d script
On Tuesday 10 July 2007 20.04:38 Russ Allbery wrote: Toni Mueller [EMAIL PROTECTED] writes: Slapd may require an external SQL server if a suitable backend is defined, and I guess that a whole slew of other applications have similar problems. You should require everything you might use directly using the Should-Start stanza, which says that you should start after those services if anything provides them but that not having them available isn't an error. Hmmm. With slapd, for example, it's certainly possible where one scenario (slapd uses SQL database) directly contradicts another scenario (startup of SQL database uses auth info which is provided by slapd). Not sure how a packager should deal with this. (slapd being used only as an example. Other scenarios for other services are certainly possible.) cheers -- vbi -- featured link: http://fortytwo.ch/gpg/intro signature.asc Description: This is a digitally signed message part.
Re: Please all dependency info into your init.d script
On Fri, Jul 13, 2007 at 07:18:17AM +0200, Adrian von Bidder wrote: On Tuesday 10 July 2007 20.04:38 Russ Allbery wrote: Toni Mueller [EMAIL PROTECTED] writes: Slapd may require an external SQL server if a suitable backend is defined, and I guess that a whole slew of other applications have similar problems. You should require everything you might use directly using the Should-Start stanza, which says that you should start after those services if anything provides them but that not having them available isn't an error. Hmmm. With slapd, for example, it's certainly possible where one scenario (slapd uses SQL database) directly contradicts another scenario (startup of SQL database uses auth info which is provided by slapd). Not sure how a packager should deal with this. (slapd being used only as an example. Other scenarios for other services are certainly possible.) Well, the OpenLDAP maintainers are likely to deal with this by declaring that a SQL server that needs to read auth info out of LDAP for startup is not supported, and the admin is on their own for making this work. All Debian system accounts should be stored in the nss_files backend, where adduser will put them by default. If your system accounts are in LDAP, you're making your system deliberately fragile, and I see no reason for Debian to make that easier to do. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please all dependency info into your init.d script
[Vincent Danjean] What about circular dependencies that must be broken differently depending on the admin configuration ? [Henrique de Moraes Holschuh] You have your answer right there: let the admin fix it. Exactly. And the insserv system provides a system where overrides are read from /etc/insserv/overrides for such use (or the admin can just edit the scripts directly). Of course, circular dependencies are a nasty problem already with the current ordering mechanism, and a source of several of the bugs in the current boot sequencing. So please add dependency information into all init.d scripts missing them today, to make it possible to detect the current circular dependencies that need to be solved before Lenny. Without dependency information, it is a lot harder to detect these problems. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please all dependency info into your init.d script
[Toni Mueller] Packages may or may not require services, depending on actual runtime configuration. Eg. roundup can use one or more out of a number of database mechanisms, some of which require external SQL servers, and at least one that doesn't. Correct. Request-Tracker may be run at least with MySQL or PostgreSQL, so require which? It should list both, as optional requirements. In other words, it should include 'should-start: mysql postgresql' (or whatever those init.d scripts are called). What if the configuration specifies one while a virtual service $sqldatabase (purely fictional) might provide only the other? Should we require both? Slapd may require an external SQL server if a suitable backend is defined, and I guess that a whole slew of other applications have similar problems. This is not as hard as you make it sound. The init.d scripts that should start before a given init.d script if present should be listed as should-start (optional), and those that are always present should be listed as required-start. To me, the one big question is why you want to stick with the SysV init script system instead of eg. switching to runit (my personal favourite, w/o having looked far, yet - but it's hard to get worse than SysV init, so...). Well, while replacing the boot system might be an interesting goal, I believe it will be a very long process to get the Debian project to agree on such change, and even longer to change all packages to use it. This is the reason I have decided to focus my effort on fixing the bugs in the current boot system using mechanism that do not depend on changing a lot of packages, and which will do the least amount of changes required to fix the problem. The current proposal is to document dependencies in the init.d scripts themselves (or override files while we wait for the init.d scripts to be updated), and then replace the update-rc.d program with a program that take these dependencies into account when creating the symlinks in /etc/rc*.d/. This will fix a few long-standing bugs in the current boot and shutdown sequence. IOW, I'm very doubtful that adding this new complexity really solves the problem instead of (maybe) making it even worse - worse, because the limited usefulness is now offset by increased changes for packaging errors and maintenance burden. Well, some of us have spent quite a lot of time thinking about the boot system, and personally I have concluded that fixing the current boot sequence is fixable in the lenny time frame, while replacing it with a completely new approach is not. I believe rewriting all 843 packages with init.d scripts to use another system is not possible at the moment, so I focus on the fix that can have most positive effect in the short to medium time frame. It is possible to have the sysv boot sequence ordered using dependency information in that time frame, as it can be done by only updating a single package while we wait for the package maintainers to add the most updated information to their package. Providing this information outside the package it not going to be maintainable, as such information will always fall out of sync with the package itself, so it is best to keep it as part of the individual init.d scripts. At the moment, 473 of 843 (56%) packages already provide the headers with dependency information, and I expect us to be able to get most of the rest to include them for Lenny. For the remaining packages, we can provide override headers outside the package as an interim solution. I suggest that we take a step back and first examine the field and determine a solution instead of rushing to action with SysV init (for no perceivable gain, imho), and if I can wish something for Lenny right now, dropping SysV in favour of a better alternative is high on my list. If you want to work on the boot system, I absolutely welcome your time and interest. The initscripts-ng alioth project and assosiated mailing list is the current gathering point. The various boot systems have been discussed on the list. You might find the discussion there interesting. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please all dependency info into your init.d script
Petter Reinholdtsen wrote: The current proposal is to document dependencies in the init.d scripts themselves (or override files while we wait for the init.d scripts to be updated), and then replace the update-rc.d program with a program that take these dependencies into account when creating the symlinks in /etc/rc*.d/. This will fix a few long-standing bugs in the current boot and shutdown sequence. What about circular dependencies that must be broken differently depending on the admin configuration ? For example, looking at openvpn and nfs : * On some machines, openvpn must depend (perhaps not directly) on nfs if /usr is nfs-mounted * On other machines, nfs must depend on openvpn because openvpn is needed to reach the nfs server This is the first example that come to my mind. I am sure we can find lots of other similar examples. How should this be solved with static headers dependencies ? Best regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please all dependency info into your init.d script
On Tue, 10 Jul 2007, Vincent Danjean wrote: What about circular dependencies that must be broken differently depending on the admin configuration ? You have your answer right there: let the admin fix it. For example, looking at openvpn and nfs : * On some machines, openvpn must depend (perhaps not directly) on nfs if /usr is nfs-mounted * On other machines, nfs must depend on openvpn because openvpn is needed to reach the nfs server We support the most common setup, then (local or not-over-openvpn-nfs /usr). This is the first example that come to my mind. I am sure we can find lots of other similar examples. How should this be solved with static headers dependencies ? It *cannot*. Heck, sometimes it cannot be solved even by dynamic (as in calculated at runtime) dependencies. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please all dependency info into your init.d script
[Neil McGovern] Blootbot requires a mysql database to be up and running, or it will fail. However, this database doesn't need to be on the local host. How's best to handle this situation in the init script dependencies? I suggest adding the mysql init.d script in the should-start header, to make sure the blootbot script is started after mysql, if mysql is installed on the same machine. I also suggest adding $remote_fs in the required-start header to make sure the network is up and all file systems are mounted before the blootbot script runs. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please all dependency info into your init.d script
On Fri, Jul 06, 2007 at 10:43:31PM +0200, Petter Reinholdtsen wrote: For this to work properly, all init.d scripts need to provide dependency information. [snip] Neil McGovern [EMAIL PROTECTED] blootbot Blootbot requires a mysql database to be up and running, or it will fail. However, this database doesn't need to be on the local host. How's best to handle this situation in the init script dependencies? Neil ps: please CC: or I may not see your mail for quite some time. -- Tolimar So we can expect stockholm to be elected in 2009? Ganneff isnt the world own3d by ubuntu then? signature.asc Description: Digital signature
