Re: /etc/init.d/ - add/remove services
In article [EMAIL PROTECTED], Thomas Hood [EMAIL PROTECTED] wrote: Miquel van Smoorenburg miquels () cistron ! nl wrote in part: A thought just hit me. What if we added a update-rc.d name enable|disable command? This has already been wished for. See sysv-rc wish #214757 No, that's not what I mean. That is a runlevel editor. I mean a generic disable-startup-at-boottime and enable-startup-at-boottime option, which is what is and sysvinit wish #67095. Yes, that's what I mean, but renaming symlinks looks ugly to me, while pointing them to /dev/null seems more elegant. Maybe it's just me. That has never been done because the implementation would be awkward and wouldn't fit into the sysv-rc design. But what if we used the destination of the symlink ? Suppose you have a service foo enabled in runlevel 2 and disabled in runlevel 3. On moving from 2 to 3 you want foo to be stopped. However, if foo is disabled in runlevel 3 by having its S entry symlinked to /bin/true then it won't be stopped. That's another issue. That should be handled by a runlevel editor. The right thing to do is to write a simple runlevel editing tool and include it in the sysv-rc package. This tool would rename Snn symlinks to K(100-nn) symlinks and vice versa K(100-nn) .. hmm, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=216028 and would keep records of what it had done so that reversion was easy. The sysv update-rc.d program would be rewritten to work through the runlevel editing tool; commands coming from update-rc.d would determine what the tool considered to be the default setting. Other init systems would implement this tool differently, of course. Ouch, complicated ... Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/init.d/ - add/remove services
On Sat, 2004-01-31 at 22:10, I wrote: Note that the expectation of the System V init system is that every service have either an S or a K symlink in each runlevel. If there is no symlink for a service in a particular runlevel then the behavior of sysv's invoke-rc.d is undefined for that service in that runlevel. Methods of shutting off services must take that into account. This is true. Suppose you have service foo that is S20 in runlevel 2 and you want to shut it off. You should do something like: /etc/rc2.d/$ mv S20foo K80foo_originallyS20 No. Further investigation has revealed to me that this won't work. The renamed symlink has to be K??foo or it won't be recognized as a foo script even though it links to foo. I conclude that the only correct way to disable a service is to do something like: /etc/rc2.d$ mv S20foo K80foo It is up to the administrator to keep a record of what the original symlink was called so that he can restore it to that name later if he wishes to do so. There are a couple of high-level utilities available that can automate this process for the administrator. Miquel van Smoorenburg miquels () cistron ! nl wrote in part: A thought just hit me. What if we added a update-rc.d name enable|disable command? This has already been wished for. See sysv-rc wish #214757 and sysvinit wish #67095. That has never been done because the implementation would be awkward and wouldn't fit into the sysv-rc design. But what if we used the destination of the symlink ? Suppose you have a service foo enabled in runlevel 2 and disabled in runlevel 3. On moving from 2 to 3 you want foo to be stopped. However, if foo is disabled in runlevel 3 by having its S entry symlinked to /bin/true then it won't be stopped. The right thing to do is to write a simple runlevel editing tool and include it in the sysv-rc package. This tool would rename Snn symlinks to K(100-nn) symlinks and vice versa and would keep records of what it had done so that reversion was easy. The sysv update-rc.d program would be rewritten to work through the runlevel editing tool; commands coming from update-rc.d would determine what the tool considered to be the default setting. Other init systems would implement this tool differently, of course. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/init.d/ - add/remove services
Note that the expectation of the System V init system is that every service have either an S or a K symlink in each runlevel. If there is no symlink for a service in a particular runlevel then the behavior of sysv's invoke-rc.d is undefined for that service in that runlevel. Methods of shutting off services must take that into account. Suppose you have service foo that is S20 in runlevel 2 and you want to shut it off. You should do something like: /etc/rc2.d/$ mv S20foo K80foo_originallyS20 As someone has already pointed out, update-rc.d is intended for use by maintainer scripts. It allows maintainer scripts to work independently of which init system is in use, whether it is the System V init system, file-rc or some other. The local administrator need not use update-rc.d to change sysv symlinks. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/init.d/ - add/remove services
In article [EMAIL PROTECTED], Thomas Hood [EMAIL PROTECTED] wrote: Note that the expectation of the System V init system is that every service have either an S or a K symlink in each runlevel. If there is no symlink for a service in a particular runlevel then the behavior of sysv's invoke-rc.d is undefined for that service in that runlevel. Methods of shutting off services must take that into account. Suppose you have service foo that is S20 in runlevel 2 and you want to shut it off. You should do something like: /etc/rc2.d/$ mv S20foo K80foo_originallyS20 As someone has already pointed out, update-rc.d is intended for use by maintainer scripts. It allows maintainer scripts to work independently of which init system is in use, whether it is the System V init system, file-rc or some other. The local administrator need not use update-rc.d to change sysv symlinks. A thought just hit me. What if we added a update-rc.d name enable|disable command? That has never been done because the implementation would be awkward and wouldn't fit into the sysv-rc design. But what if we used the destination of the symlink ? The disable command would simply walk over all symlinks in /etc/rc?.d of the form ^S\d+name$ and point them to /bin/true. The enable command would do the reverse, point the symlinks back to /etc/init.d/name. That would keep the essence of any local config, and would make it trivial to switch services on and off. Anyone looking at it would also intuitively understand what was going on. Ofcourse invoke-rc.d should know about this, and file-rc needs to be updated (it can easily store this state in its config file I think) but otherwise implementation should be trivial. Only thing is - should the links of the disabled service point to /bin/true or to some special, non-existing location that is easy to detect with test -e ? Or perhaps use /dev/null, which is detectable with test -e file ! test -s file ? I see that currently /bin/true is a small ELF binary, not a shell script anymore, so it would't be too much overhead to run it. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/init.d/ - add/remove services
On Friday 30 January 2004 03:15 pm, [EMAIL PROTECTED] wrote: What is the preferred way to add or remove a /etc/init.d/ service from certain runlevels? For adding, use the update-rc.d script. To remove, just manually delete the symlink. You can use update-rc.d to remove, but you would need to first remove all the symlinks, then add the set that you want. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/init.d/ - add/remove services
Incoming from Adam Aube: On Friday 30 January 2004 03:15 pm, [EMAIL PROTECTED] wrote: What is the preferred way to add or remove a /etc/init.d/ service from certain runlevels? For adding, use the update-rc.d script. To remove, just manually delete the symlink. You can use update-rc.d to remove, but you would need to first remove all the symlinks, then add the set that you want. Alternatively, leave the links alone and just manipulate the scripts in /etc/init.d themselves. If you don't want something to run, insert exit near the top of the script (after the shebang line). -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: /etc/init.d/ - add/remove services
-Original Message- From: s. keeling [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 12:39 PM To: [EMAIL PROTECTED] Subject: Re: /etc/init.d/ - add/remove services Incoming from Adam Aube: On Friday 30 January 2004 03:15 pm, [EMAIL PROTECTED] wrote: What is the preferred way to add or remove a /etc/init.d/ service from certain runlevels? For adding, use the update-rc.d script. To remove, just manually delete the symlink. You can use update-rc.d to remove, but you would need to first remove all the symlinks, then add the set that you want. Alternatively, leave the links alone and just manipulate the scripts in /etc/init.d themselves. If you don't want something to run, insert exit near the top of the script (after the shebang line). I don't know if there is a preferred way. There are many ways and choose the one you like. The convention I use is to rename the file/link with a no in front. e.g. mv /etc/rc3.d/K96pcmcia /etc/rc3.d/noK96pcmcia mv /etc/rc3.d/S50snmpd /etc/rc3.d/noS50snmpd That way if I ever want to put it back, I know where the original file was . The advantage it would have over the exit method above is that by doing an ls on the /etc/rc*d directories you can see what services are started/killed clearly and also what services used to be started/killed by the no in the filename whereas with the exit you'd have to look in the file itself to find that the service was being killed. Also, you have finer control over the runlevels. Putting an exit in the script will kill the service for all runlevels. Whereas renaming a link will kill for an individual runlevel. THe disadvantage is if you do want to disable the service altogether, you wlil have to possibly rename up to 6 scripts where as in the exit method you just have to edit one script. Just another alternative. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/init.d/ - add/remove services
On Friday 30 January 2004 04:36 pm, Ben Yau wrote: I don't know if there is a preferred way. There are many ways and choose the one you like. The convention I use is to rename the file/link with a no in front. That reminds me of another way - rename the capital S or K to a lower case. Same benefits/drawbacks as the method you describe. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/init.d/ - add/remove services
[EMAIL PROTECTED] writes: What is the preferred way to add or remove a /etc/init.d/ service from certain runlevels? 'ln -s' and 'rm', respectively. The Debian Policy Manual and man pages suggest I should use update-rc.d rather than manipulate the symlinks directly. They suggest that *Debian packages* use update-rc.d, not system administrators. I have searched around and in the past, people have suggested to just manipulate the symlinks directly. Is this still the case? Yes. The Debian infrastructure treats those as user configuration and doesn't change them, provided you've left at least one symlink around. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: /etc/init.d/ - add/remove services
-Original Message- From: Adam Aube [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 1:51 PM To: [EMAIL PROTECTED] Subject: Re: /etc/init.d/ - add/remove services On Friday 30 January 2004 04:36 pm, Ben Yau wrote: I don't know if there is a preferred way. There are many ways and choose the one you like. The convention I use is to rename the file/link with a no in front. That reminds me of another way - rename the capital S or K to a lower case. Same benefits/drawbacks as the method you describe. Adam Another excellent alternative. For me, it's easier on the eyes to see the no in front to know that it's not running vs comparing s to S. Again, just personal preference. They're all good and they all work- Ben Yau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/init.d/ - add/remove services
Thanks for all your replies. You've cleared this up for me. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
