Init.d script, preventing start of one service
Hello, In one of the package i maitain i have a config script which begin by asking if the service attached to this package need to be run. I use a variable ( stored in /etc/default/mldonkey -- LAUNCH_AT_STARTUP=yes ) to determine if i need to run the service or not. If the variable is set to yes, the init script launch the service, otherwise it does nothing. The user ask me if i can use update-rc.d to create/remove symlink depending on the former LAUNCH_AT_STARTUP value. What is the standard solution for doing this in debian ? Thanks for your response Kind regard Sylvain LE GALL ps : i know ssh use a file to launch or not sshd, is it a good solution ?
Re: Init.d script, preventing start of one service
On Tue, Nov 11, 2003 at 04:27:03PM +0100, Sylvain LE GALL wrote: ps : i know ssh use a file to launch or not sshd, is it a good solution ? No, I don't think it is a good solution. I'm planning to split the ssh package into openssh-client and openssh-server at some point, which will get rid of that whole ugly edifice (and close several bugs as a result). I think having services in their own packages which you can uninstall if you don't want to run them is better than /etc/default cruft. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Init.d script, preventing start of one service
On Tue, 11 Nov 2003, Sylvain LE GALL wrote: In one of the package i maitain i have a config script which begin by asking if the service attached to this package need to be run. I use a variable ( stored in /etc/default/mldonkey -- LAUNCH_AT_STARTUP=yes ) to determine if i need to run the service or not. If the variable is set to yes, the init script launch the service, otherwise it does nothing. The user ask me if i can use update-rc.d to create/remove symlink depending on the former LAUNCH_AT_STARTUP value. What is the standard solution for doing this in debian ? 1. leave update-rc.d alone. Register the init script and be done with it. 2. setup the init script to source /etc/default/mldonkey, and block the start (return ok status BTW) if LAUNCH_AT_STARTUP is not true. This is not the best solution, but it is the current best-practice. ps : i know ssh use a file to launch or not sshd, is it a good solution ? No. -- 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
Re: Init.d script, preventing start of one service
I am redirecting to debian-mentors, imho the more appropriate list. On Tue, Nov 11, 2003 at 04:27:03PM +0100, Sylvain LE GALL wrote: In one of the package i maitain i have a config script which begin by asking if the service attached to this package need to be run. I use a variable ( stored in /etc/default/mldonkey -- LAUNCH_AT_STARTUP=yes ) to determine if i need to run the service or not. If the variable is set to yes, the init script launch the service, otherwise it does nothing. I think that is the best solution currently possible. The user ask me if i can use update-rc.d to create/remove symlink depending on the former LAUNCH_AT_STARTUP value. IMHO it is dubious whether you are allowed to do that, it would work *basically*[1] like this in postinst: -- db_get mldonkey/runservice runme=$RET if [ $RET = true ] update-rc.d -f remove mldonkey update-rc.d mldonkey defaults else update-rc.d -f remove mldonkey update-rc.d mldonkey stop 20 fi ... invoke-rc.d mldonkey start -- And invoke-rc.d will only start the service if it has a start-entry in the sysvinit system for the current runlevel. The big problem is that you loose user configuration, i.e. if $user has set up his system to run mldonkey only in runlevel5 you will nuke it. And there is no way around it, as it is impossible to query what links currently exist. (You cannot do ls in the symlink-directories, see file-rc), you may only interface with the init-stuff with invoke- and update-rc.d. What is the standard solution for doing this in debian? Afaict the standard solutions are: - ship daemon and clients in separate packages (ftp, ssh, nfs, ...) to circumvent the problem (no option for mldonkey afaict) - Choose a default and let the user change it by hand instead of via dpkg-reconfigure. ps : i know ssh use a file to launch or not sshd, is it a good solution? Imnsho it is worse than using the default-file. - The default file at least provides a rather standardized location. cu andreas [1] There is lots of sugar-coating necessary, you don't want remove+(set again) if there was no change. -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Init.d script, preventing start of one service
Hello, On Tue, Nov 11, 2003 at 02:17:03PM -0200, Henrique de Moraes Holschuh wrote: On Tue, 11 Nov 2003, Sylvain LE GALL wrote: In one of the package i maitain i have a config script which begin by asking if the service attached to this package need to be run. I use a variable ( stored in /etc/default/mldonkey -- LAUNCH_AT_STARTUP=yes ) to determine if i need to run the service or not. If the variable is set to yes, the init script launch the service, otherwise it does nothing. The user ask me if i can use update-rc.d to create/remove symlink depending on the former LAUNCH_AT_STARTUP value. What is the standard solution for doing this in debian ? 1. leave update-rc.d alone. Register the init script and be done with it. 2. setup the init script to source /etc/default/mldonkey, and block the start (return ok status BTW) if LAUNCH_AT_STARTUP is not true. This is not the best solution, but it is the current best-practice. OK, i take this in note. ( it is the current scheme ). Thanks Kind regard Sylvain LE GALL
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Mon, Nov 10, 2003 at 11:26:24AM -0600, Adam Heath wrote: On Mon, 10 Nov 2003, Branden Robinson wrote: Uh, what if I want to put the following at the very top of my debian/control file? # $Id$ I was given to understand that dpkg 1.10.15 or so would be just fine with it, whereas dpkg 1.9.21 or so would vomit all over it. Placing comments in the leading paragraph may cause problems with older versions. However, for buildds, the build-depends will already be installed by the time your package is unpacked, so in practice, I doubt this is of much concern. Is there a reason we need to preserve the (presumably existing) requirement that debian/control exist in the .tar.gz or diff.gz? What is debian/control used for during package unpack? -- G. Branden Robinson| If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
