Here are a couple of scripts which I find useful. The first is trivial; it is a port of Redhat's (& Mandrake's) 'service' script. It's all of three lines. It allows the user to say 'service qmail restart' rather than '/etc/init.d/qmail restart', and it is amazingly handy for such a stupid little script. The reason being that it is much easier to type. Try it, you'll like it. The script is in /bin/sh. The second script is more substantial. I call this script rc-status, and it prints information about the rc services that are installed and their run status. This provides an /overview/ of the RC system. I find that it is very easy to have 'orphaned' init.d scripts; scripts which were installed, but never 'enabled' with rc-update. It took me a good three days after first installing Gentoo to realize that cron wasn't enabled by default :-/. In any case, this script can be used to show the status of all services defined at this runlevel, as well as print out a list of all services which are installed but not enabled. By default, the script displays information about the current run level. If a symbolic name is provided, it displays information about that run level instead. If --all (-a) is provided, it displays information about all run levels, including 'orphaned' services. If --unused (-u) is provided, it displays a list of services which are installed, but not assigned to any run level. --help (-h) displays usage information. --list (-l) shows a list of all run level symbolic names defined for the system. --nocolors (-n) turns off colors in the output. The script is written in Ruby. I don't do Python. I commented it copiously, so if someone wants to do a conversion to Python, it shouldn't be difficult. There are 91 lines of non-blank, non-comment code; 185 with comments. You could redo it in /bin/sh; more power to you. I've got a low threshold for pain, so it is in Ruby. I'd like to see these either in baselayout, or one of the extension libraries, such as gentoolkit. Wherever is appropriate. I hesitate to make an entire ebuild for these two scripts, but I will if I need to. Thanks.
Created attachment 1828 [details] A script to provide summary information about the system RC status
Created attachment 1829 [details] A really, really small script that is really, really convenient.
rux0r root # rc-status /usr/sbin/rc-status:149:in `open': No such file or directory - "/mnt/.init.d/failed" (Errno::ENOENT) from /usr/sbin/rc-status:149:in `entries' from /usr/sbin/rc-status:149
Hmm. I didn't know that /mnt/.init.d/failed (and I'd assume /mnt/.init.d/broken) was an optional directory. I thought they were part of the rc system. In any case, I've attached a patch that fixes this problem, and ignores those directories if they don't exist.
Created attachment 1843 [details, diff] A patch to catch missing directories in /mnt/.init.d
if you need more info about my setup to make this work, just ask rux0r root # rc-status Runlevel: default local [ started ] netmount [ started ] net.eth0 [ started ] sshd [ started ] samba [ started ] metalog [ started ] dcron [ started ] /usr/sbin/rc-status:176: undefined method `include?' for nil (NameError) from /usr/sbin/rc-status:171:in `each' from /usr/sbin/rc-status:171 from /usr/sbin/rc-status:167:in `each' from /usr/sbin/rc-status:167 apache
Created attachment 1855 [details, diff] Incremental patch to fix nil error This bug that vapier is seeing really shouldn't occur; it can't, theoretically, occur. However, this patch ensures that it doesn't occur.
i cant test out that patch on rux0r (the ps went up in smoke, literally) ... ill tested it out on my desktop and it worked great :)
*** Bug 2467 has been marked as a duplicate of this bug. ***
Ok, just got home, and yesterday evening the power was out the whole night :( Anyhow, rc-status looks like a gem, which we can either have in baselayout, or maybe gentoolkit (will have to check with Karl). Side note though, is if in baselyout, ill rather like to have it in bash, using /etc/init.d/functions.sh for output. We can even change eend() to have a third optional parameter to change the default output (ok, or status, etc). My ruby sux though :/ Then for the service script. We have talked about this before, and I dont like it .. many other users/developers dont like it, or feel it is not safe (dont want initscripts in $PATH). I really feel it is a user-domain thing .. if you want it, you can do the 3 lines of bash code.
Martin Schlemmer: where do you live ? my power went out last evening also ;) which leads to why rux0r's PS went up in smoke at any rate i would have to agree on both points ... rc-status *should* be in bash (i lub bash, i had to bring down ruby on my boxes in order to test out your script) the service thing should be a user preference ... if you want it, add the 3 lines ... hell, make it an alias for the super user in /etc/profile ;)
'bash' /is/ the LCD, and there's good reason to have only bash scripts in the baselayout. That said: 1) All non-trivial bash scripts inevitably becoume unmanageable. rc-status wouldn't be exactly trivial to implement in bash. Therefore, I'd personally rather see it in gentoolkit than in baselayout if bashness is a prerequisite for baselayout. 2) rc-status isn't exactly a core feature; nobody is going to die for not having rc-status installed. Another argument for having it in gentoolkit. 3) If someone else wants to rewrite it in bash, that is fine by me. I'm not going to do it, though :-) Martin sez: > for output. We can even change eend() to have a third optional parameter to > change the default output (ok, or status, etc). My ruby sux though :/ I think the array operations would be the most complicated thing to translate to bash. I think Python would be a better target for translation. Most of Gentoo depends on Python, so it is installed by default. I thoroughly dislike Python, though, so (again) I won't be doing a translation. > Then for the service script. We have talked about this before, and I dont > like it .. many other users/developers dont like it Hm. Yeah, I just found bug #2467. Well, I'm coming from Redhat and Mandrake, and the 'service' function is a sanity feature. Anybody who spends any real time doing sysadmin knows that you tend to call the rc scripts a lot by hand, when you're upgrading, installing, configuring, and fixing. In any case, I don't really care if 'service' makes it into the distribution; I submitted it as an enhancement because I don't know of a better place for people to submit utility scripts, and as much as some Gentoo users may not like it, a lot of people coming from just about any of the other major distros are going to miss this basic functionality. I thought I'd throw it out there. <shrug/> > or feel it is not safe (dont want initscripts in $PATH). This, I don't understand. 'service' doesn't put initscripts any nearer to the $PATH than prepending the full path does. It is merely easier to type the word 'service ' than '/etc/init.d/'. Oh, and I got the pun, Martin :-)
> 1) All non-trivial bash scripts inevitably becoume unmanageable. rc-status > wouldn't be exactly trivial to implement in bash. Therefore, I'd personally > rather see it in gentoolkit than in baselayout if bashness is a prerequisite > for baselayout. > > 2) rc-status isn't exactly a core feature; nobody is going to die for not > having rc-status installed. Another argument for having it in gentoolkit. > 3) If someone else wants to rewrite it in bash, that is fine by me. I'm not > going to do it, though :-) True. > I think the array operations would be the most complicated thing to translate > to bash. I think Python would be a better target for translation. Most of > Gentoo depends on Python, so it is installed by default. I thoroughly dislike > Python, though, so (again) I won't be doing a translation. This was ideas for a bash rewrite. >> or feel it is not safe (dont want initscripts in $PATH). > > This, I don't understand. 'service' doesn't put initscripts any nearer to the > $PATH than prepending the full path does. It is merely easier to type the > word 'service ' than '/etc/init.d/'. This is not my argument .. just came up with a previous discussion. > Oh, and I got the pun, Martin :-) Ok, I dont know what "pun" means ;)
Hi Karl .. mind having a look at rc-status for inclusion in gentoolkit? Thanks.
I haven't tried this as I don't have Ruby installed, but from what I read here, I'd vote for thsi to be re-writted in something that would allow it's inclusion in the base system. To be honest, I don't understand why gentoolkit is not a part of it either. Yes, you CAN survive without gentoolkit installed, but it's small and who would NOT WANT to have it installed ?
Created attachment 2738 [details] the /usr/sbin/rc-status script rewritten in bash since everyone wants it but noone wants to do it, please test this out and tell me it works ;) also, please audit the source code real quick as this is the first real bash script ive done that doesnt consist of just 1 or 2 if statements
*** Bug 5820 has been marked as a duplicate of this bug. ***
*** Bug 7123 has been marked as a duplicate of this bug. ***
*** Bug 7141 has been marked as a duplicate of this bug. ***
*** Bug 12479 has been marked as a duplicate of this bug. ***
I found this from Bug 12479, tested and it works great. Whats the status of this? Is it going to be included in gentoolkit or what?
Created attachment 6847 [details, diff] rc-update patch to list services I know there were previous attempts at getting this functionality for rc-update. This is just an idea. It adds a "show" command-line arg to rc-update, which lists all available scripts in /etc/init.d and the runlevels for which they'll execute. If no runlevels are specified, rc-update will list all runlevels otherwise just specified runlevels will be shown. This patch also ignores any .sh functionality scripts in /etc/init.d. please be gentle... :-)
taking so i can add it
Created attachment 8349 [details] updated rc-status (works with latest baselayout) actually i lied, it doesnt belong in gentoolkit, it belongs in baselayout ... back to you az ;)
Created attachment 8350 [details] more touchups
Added to CVS (or about to), thanks guys. Sorry for being so long overdue ...
