I, aswell as many others (i assume) would like to see SysV compatible runlevels. I'm not saying that you should drop the dependecies, i'm just saying that a few more runlevels avail by default, with simple priorities would be nice. Aswell as a better way of managing them (see chkconfig on rh/mdk, which also manages xinetd). Don't get me wrong, the dependecy style rocks, but for some admins propper runlevels with a good tool to view them is something that you benefit from. Reproducible: Always Steps to Reproduce: 1. 2. 3.
We use sysvinit with a wrapper (/sbin/rc). If you want to add more runlevels, that's easy, if you want to use old-style runlevels, that's also easy. Azarah can provide more information than I can, but I believe the rc-scripts guide on the website discusses some of these things. You might not want to assume that many others want it. Our current runlevel system is one of the major selling points for Gentoo according to most of the users I've talked to.
I never said that you should drop the current functionallity. I'm just saying that a default behavior with more runlevels and a better way to view them is something that i and i think most ppl interested in running a server would look for. SysV only means that you'll have 1 -> 5 and priorities within them, nothing about droping existting enhancements. As i see it, i would never run gentoo on a server since it would cost me to much grief to get it working propperly. I actually have problems running it as a desktop due to the runlevles, and "doing it all manually" is not a answer. I'd rather change dist. And as this wouldn't change anything for existing users that would still have a aliased "default" runlevel i see no reaon not to do it, after all, sysv is a good standard once you really use it.
SysV style init levels are messy and obsolete. Priorities within a runlevel exist to handle dependencies, which is why we have dependencies instead - why work around a problem when you can address it correctly? We moved away from SysV-style init for a reason. It's very incomplete, obsolete, and barely even understandable without a significant degree of critical thinking. We didn't just randomly decided to drop SysV-style init levels for fun. Why would running Gentoo on a server cause you "grief"? Can you point out specific scenarios where this might be problematic?
SysV init is logicall... And as i said, no need for reversing. I just think that a system which has a chkconfig like utility and multiple runlevels (not just 3 aliased runlevels) would be a benefit for server admins. I generally use runelevls when trouble shooting or when i want to shutdown a certain amount of services. Having propper runlevels just simplifies the way thinsg work. Ie, lets say that gentoo gets all "standard runlevels"... the scripts for X/xdm etc could have a dependency on runlevel 5 like most dists do (when adding to default, default becomes 5)... No loss for the average user, but a huge advantage for server admins. And as a sidenote, i'm only using gentoo since i like the general idea, while some packages are just a frew minutes old and some is a year old.. I can live with that... But dropping good working systems for systems with less granulatrity when a merger would be better is kinda dumb imho. (Have you seen chkconfig in action, for overview it rocks.)
You can have that. Did you read the guide I referred you to? You can actually have many more than what a standard sysvinit allows you to have. http://www.gentoo.org/doc/en/rc-scripts.xml Please read it over before commenting further on things like the number of runlevels you can have. Why would we need chkconfig when we have rc-update?
For sysadmins: chkconfig --list atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off gpm 0:off 1:off 2:on 3:on 4:on 5:on 6:off nfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off rcd 0:off 1:off 2:on 3:on 4:on 5:on 6:off usb 0:off 1:off 2:on 3:on 4:on 5:on 6:off xfs 0:off 1:off 2:on 3:on 4:on 5:on 6:off alsa 0:off 1:off 2:on 3:on 4:on 5:on 6:off cups 0:off 1:off 2:on 3:on 4:on 5:on 6:off ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off kheader 0:off 1:off 2:on 3:on 4:off 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off kudzu 0:off 1:off 2:off 3:off 4:off 5:off 6:off netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off snmpd 0:off 1:off 2:off 3:on 4:on 5:on 6:off sound 0:off 1:off 2:on 3:on 4:on 5:on 6:off harddrake 0:off 1:off 2:off 3:on 4:on 5:on 6:off iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off ip6tables 0:off 1:off 2:on 3:on 4:on 5:on 6:off rawdevices 0:off 1:off 2:off 3:on 4:on 5:on 6:off devfsd 0:off 1:off 2:on 3:on 4:on 5:on 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off nfslock 0:off 1:off 2:off 3:on 4:on 5:on 6:off medusa 0:off 1:off 2:off 3:on 4:on 5:on 6:off random 0:off 1:off 2:on 3:on 4:on 5:on 6:off smartd 0:off 1:off 2:off 3:on 4:on 5:on 6:off syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off upsmon 0:off 1:off 2:off 3:off 4:off 5:off 6:off numlock 0:off 1:off 2:off 3:on 4:on 5:on 6:off anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off xinetd 0:off 1:off 2:off 3:on 4:on 5:on 6:off partmon 0:off 1:off 2:off 3:on 4:on 5:on 6:off portmap 0:off 1:off 2:off 3:on 4:on 5:on 6:off keytable 0:off 1:off 2:on 3:on 4:on 5:on 6:off proftpd 0:off 1:off 2:off 3:on 4:on 5:on 6:off internet 0:off 1:off 2:off 3:on 4:off 5:on 6:off xinetd based services: cvs: off fam: on echo: off tftp: off time: off daytime: off rsync: off servers: off proftpd-xinetd: off cups-lpd: off chargen-udp: off services: off daytime-udp: off time-udp: off echo-udp: off chargen: off Imagine how much info you get with a simple grep. And then you have the multiple levles and overview. (NOTE since i suggested this as a enhacnement i obviusly mean the default behavior not the *i'll modify the hell out of this distro just to make it work great with what i'd call 'common granularity'.)
Reading the manual and using mkdir once is "modifying the hell out of it"?
it's managing it all manually. Nothing that i'd feel like doing in a system like that. I have no problem with common sysv when it comes to manual editing eventhough it can be a pain. And yes, i'd call making a dir, filling it with symlinks / runlevel "modifying the hell out of it"
I do not understand the issue. Instead of /etc/rc.d/rc[0..6].d, we just have named ones. Meaning you could create directories: ---------------------------- /etc/runlevels/rc0.d /etc/runlevels/rc1.d .... ---------------------------- And then change /etc/inittab: ------------------------------- l0:0:wait:/sbin/rc shutdown l1:1:wait:/sbin/rc single l2:2:wait:/sbin/rc nonetwork l3:3:wait:/sbin/rc default l4:4:wait:/sbin/rc default l5:5:wait:/sbin/rc default l6:6:wait:/sbin/rc reboot ------------------------------- to: ------------------------------- l0:0:wait:/sbin/rc rc0.d l1:1:wait:/sbin/rc rc1.d l2:2:wait:/sbin/rc rc2.d l3:3:wait:/sbin/rc rc3.d l4:4:wait:/sbin/rc rc4.d l5:5:wait:/sbin/rc rc5.d l6:6:wait:/sbin/rc rc6.d -------------------------------- Or, you could be just a bit more creative: -------------------------------- l0:0:wait:/sbin/rc shutdown l1:1:wait:/sbin/rc single l2:2:wait:/sbin/rc nonetwork l3:3:wait:/sbin/rc network l4:4:wait:/sbin/rc default l5:5:wait:/sbin/rc xfree l6:6:wait:/sbin/rc reboot -------------------------------- And 'rc-update add foo bar' as needed.
I think it will become clear to you if you read the history... (notice, this is listed as enhancement, not bug.)
What I am saying is: We do not use it how you want by default. And IMHO, trying to support both at the same time (meaning all the crud in /etc/rc.d/) will be a PITA, and plain unneat. To get what you want, is fairly easy to do without hacking things to pieces like I showed ... All the 'gears' are there, you will just have to make the required changes. Anyhow, as I also pointed out, we still have runlevels 1-5, we just 'name' them to have more destinction/clarity.
I stated this several times to the other ppl. Reworking the way you made it work is not an option imho. But i also think that having a finer granularity would be a real benefit. I'm not saying *screw this, it's gotta be hardcore SysV*. I'm just saying that any person fiddling with servers or so will need several runlevels. Even i as a users make use of runlevels all the time (took some time before i really got a hang of all the details (was spoiled with rh/mdk)). And, tools like chkconfig in rh/mdk that gives you a easy to read layout of all runlevels, i mean chkconfig --list |grep ssh will give me all the info in a easily understandable line. and, if you do a alias 1 single, 2 no net, 4 default, 5 x... Then you'll have your current behavior with all the benefits that sysv adds. Also, you could have a depend_on_init=<nr> etc... So that f.ex. ssh is started if admin wants runlevel 3, but not x and xfs.. etc. If you ever have some disks dying or crashing you'll curse not having sysv (if you have no replacement disks with a preinstalled dist).
The tools, yes there is a lack I must admit. The runlevels ... I do not know how I should make you understand its still 1,2,4,whatever, just with diff names. Or do you want a /etc/runlevels/xfree as well (seeing that there is a default [net maybe] and nonetwork already). Somewhere with this one we are not seeing eye to eye on what the other means/wants ...
Yeah, the tools is a important part. And yes, i understand that it's verry flexible and you can do just about anything, but since i sent this as a enhancement i'm more into what the standard dist looks like. I mean, if i wanted to i could probobly hotwire any dist or make my own if i'm mad enugh, but... thats besides the point. My prefered standpoint would be something like: one dir for each SysV runlevel. then ln -s the current system to these dirs. Ie, default *will work* as it is, nonet will work like it is. But this also gives any user the flexibility to run things earlier or later. And, imho, a rc-update add blah default should check the 'blah init script' for it's prefered runlevels (main point is, it will be running when default hit's the mark). But for users this would mean that ssh would be running when xfs rebuilds it's font cache or any other odd service that might do something slow (like starting up gdm/x). (and yes, i do think sshd is being run before xfs, but the machine isn't in runlevel 3 so you have to wait for it to finish afair) I would see this as what i listed it as, a enhancement... Do you see my point? What should i clarify?
Right, so shoot calling them 'default' etc, or rather, make them symlinks to whatever in /etc/rc.d/???, and in those have the S??service and K??service. If so, then the answer is NO. Short reason for this, is that you cannot have that, and as we have things now. Its either dependencies, OR the S??service/K??service stuff, not both. If you want to have some services started before another for no reason that can be classified as a dependency, then we have the 'before' and 'after' keywords, etc. Yes, our way of doing things is different from the SysV idea in general, and might be a steep learning curve ... just like SysV was the first time. The rc-system as its now, is one of Gentoo's 'defining' points, and throwing that away, will offend more people that not (IMHO) ... almost the same thing as Slackware going over to SysV from their bsd style. I am open to useful/clean addon utils that could make things more manageble. Also, I know that docs could do a nice rewrite from somebody that are more creative with wording than me, but for 100% pure SysV ... no, sorry.
First of all, i never said adobt the S and K api. I said, multiple runlevels and since they are tun linearly, you have some basic piority. And yes, i know it's what makes gentoo special to you ppl. All i'm saying is that a system could really benefit from finer granularity... Ie, current system, but all runlevels precent as default. The 'scripts' can request a runlevel else it ends up in runlevel-blah. No real problem really, see it as a finetuned version of the one your currently running.
> Ie, current system, but all runlevels precent as default. The 'scripts' can > request a runlevel else it ends up in runlevel-blah. No real problem really, > see it as a finetuned version of the one your currently running. Right, so maybe I am dense, or maybe its because its after midnight, but I do not see what you want? # rc-update add foo boot # rc-update add bar default # rc-update add zar my_own_custom_runlevel Switch on the fly: # rc nonetwork # rc default
This was suggested as a dist enhancement, not as a hack-and-trash. Imagine running a server, and you encounter some errors... then you boot with single... check the disks quickly, and then fast in to init 3... not starting x or any other such services. Then you have the basics you *need* on the server. And several consoles. If you had read the backlog you'd see that ppl has pointer this out before. All i say is the finer granularity of multiple levles and the benefits it could give your current init system is huge. But i also think that boot/default/foo/bar should be aliases, not the runlevels themseleves, that way users could set "default" to a runlevel and have it boot to that level on startup. And yes, i have been playing with init on several versions of solaris and several linux dists (rh, mdk, debian and gentoo). I have pointed out the things i see as benefits, that should be used without any loss or problems for the user since it would look and work JUST AS IT IS NOW, but you could USE the granularity. Like, ssh should start in init 3, and, x and it's pals in 5. That way you have that seperated and don't *have to* boot in to X directly f.ex. Setting the the default level could be a simple /etc file with a number in it or so... i mean how hard can it be?
Its only called 'default' because most users do not need another runlevel. You still can change in /etc/inittab which one you want to be default. Secondly, YOU DO NOT HAVE TO BOOT INTO X DIRECTLY. Rename /etc/runlevels/default to /etc/runlevels/net, change /etc/inittab for this. Make sure you only have sshd/whatever added to it. Create a /etc/runlevels/xfree. cp /etc/runlevels/net to it, and add xfs and xdm. Setup the 'net' runlevel as default, boot. Note that no xfs or xdm are started. Run 'rc xfree' as root ... my word, xfs and your DM are started. If you really wanted, you could keep 'net' hooked to runlevel 3/4, and change 'xfree' to be hooked to init runlevel 5, but this is not needed with Gentoo ... MEANING, you can have many more runlevels than those provided by init. I think you do not really know how things work in Gentoo.
Yes, i can do all that i can also workaround your network config etc etc etc etc etc etc etc etc etc. But since this is a Dist enhancement, were not talking about what *i* can do. We're talking about the basic layout of the distribution as is. I know how it works, thank you, if you had read the backlog you'd have seen that all of this discussion has already been covered. I could do all that and then some, i could hack just about anything i wanted and make the network scripts work propperly in a updatable fasion etc etc etc etc etc tec etc but, none of that changed the basic layout of the dist, now does it? READ THE DAMN BACKLOG! I have explained it all over and over again, and i get the same reply but this time in a patronising manner. I don't really care if it gets included or not, i just want someone to actually understand my viewpoint and it's not that hard really. This is like the network config bit all over again,,, *sigh*
I think Azarah and I are agreed at this point that this is _not_ a change worth making because most people do _not_ need more runlevels and the minority that do can easily add their own with no real work involved. I, personally, would recommend closing this as WONTFIX...
Thats up to you, and i'm frankly getting tired of explaining it all over again and again.
Not that azarah and avenj wound't be enough input, but I agree with them as well (close, won't fix). This suggested enhancement would not be a good addition to our init layout. The suggestion in #9 from Azarah is a way to accomodate this. Regards, Jay
Fine by me, i assume i'll be jumping dist yet again. (no it's not just this)
I guess this can be closed. It doesn't seem that our init system will change. While I agree that it can be enhanced I don't think that plain sysv is the way to go. Personally I never understood the need for all those unused runlevels or their numbers. The gentoo system is much clearrer and actually easier to understand.
we have `rc-status` to view runlevels and their init scripts and like they said, you could always just add your own ;)
