Re: runlevels remodeled
I'd counterpropose to make this optional. I very much like the fact that the runlevels have no default meaning and would prefer it to stay that way, although I can see the issue of LSB compliance. Personally, I hate that it isn't a standardized way to get down to a minimal system, or a standardized way to start everything bug *dm/X. I've seen this discussion crop up a few times, and I've had a few things on my mind along these lines for ages. I'm not sure if I can send to the group, as I'm not subscribed to it in any way. Anyhow, here comes a more or less normal persons long-held perspective... The progressive nature of the LSB run levels is good for tracking down some problems. I set my system up that way long before I ever read any discussion on it, and have used it over the years to track down a few problems by progressively bringing the system up in stages. Having four identical runlevels makes less sense than having progrssive run levels. In either case, if you want to change it, you can. In fact, I'd suggest that it's easier to make them all the same, then to switch from that to LSB behaviour. As a desktop user, I duplicated the LSB runlevel 5 down to 4, and used 5 to pack my own stuff into ([EMAIL PROTECTED], a few little services I've written for my self (okay, not not QUITE a regular user ;) ), and so forth. For a commercial/server situation, the LSB's duplication in rl 3/4 would probably be better. In either case, setting the run levels up as I'd like is difficult, and worse still that anything installed just gets tossed into all runlevels, leaving you to hunt through the list of packages for the new ones so you can put them where you want them. Personally, sometimes I'd rather they don't go into any runlevel, or maybe only runlevel 5, or even an extra unused runlevel that contains everything, and the rest with next to nothing that you can add things into as you go along. Either of these two options would be infinitely better than every new service being hurled with no rhyme or reason into every single runlevel. Of course, better still, would be a way to configure, somewhere, which runlevels a newly installed service should go into. And then the runlevel system is already divided by priorities, with certain priority ranges being used for certain tasks. So perhaps some system could be set up related to that for default runlevel filling. But at the end of the day, a very basic runlevel 1, a fairly complete runlevel 5, and a means to easily configure the runlevels without losing any (a problem with some of the older runlevel editors I've used), especially losing information about what priority the service is supposed to be started/stopped at, is essential, I think. Fredderic ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Fredderic writes: But at the end of the day, a very basic runlevel 1, a fairly complete runlevel 5, and a means to easily configure the runlevels without losing any (a problem with some of the older runlevel editors I've used), especially losing information about what priority the service is supposed to be started/stopped at, is essential, I think. If you've had any such problems with sysvconfig please file bug reports. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
[Henning Makholm] Perhaps I'm just missing some specific technical definition of multiuser, but what you describe sounds like single user, multitasking. This is old Unix jargon. Multiuser mode is where regular logins and shells are supported - specifically you've got gettys running to let people log in on various terminals, and possibly inetd and sshd. Single-user mode means you have a root shell at the console, and no other ways to log in. It has nothing to do with whether people actually log in to those gettys as different users. And at any rate, Debian isn't commercial Unix; as such, we don't have a mechanism (or a licensing reason) to limit how many unique users can log in at once. signature.asc Description: Digital signature
Re: runlevels remodeled
On Fri, 12 Aug 2005, Javier Fernández-Sanguino Peña wrote: On Fri, Aug 12, 2005 at 09:52:38AM -0500, John Hasler wrote: Timo Aaltonen writes: Is there will to change the current policy regarding runlevels in Debian? I'd propose to use the recommendation made by LSB: Please check the archives. This has been discussed many times. It is clear that there is going to be no change. The last sentence is not true. For some of the compelling reasons as to why this should change please review the last time we discussed this [0] (when I brought the issue up in my TODO stuff for etch [1]). Hmm, just proves that I can't do a proper search ;) Somehow I've missed those threads, but have read them now. To break my proposal into two separate pieces, we have: 1) moving unnecessary stuff out of rcS.d Seems to have gotten support from developers. Some disagreement whether NFS-mounts should or should not be done here. I'd say that without network you get no mounts, either ;) Those special installations that have /usr as a NFS-mount shouldn't need anything from there. Besides, automount is banned here so it's not an option. Should there be a separate discussion as to what to move away? 2) define more out-of-the-box runlevels This has been discussed before as pointed out. Some say that current situation is a feature, and others would like to see Debian take a similar scheme as other distributions. I think it is a moot point to say that having more multi-user runlevels confuses users, because ordinary users should never run into a situation where those are really needed. For sysadmins the change is a needed one. DIY-philosophy should actually be left to those who really want to customize their runlevels 2-5 =) Then those who like the proposal and those who have to bear with mixed environments can have their's left as default. Here's my short summary of some situations where those different runlevels are needed: 1 single-user, no network, only rootfs (or all local fs's?) mounted -pretty obvious 2 multi-user, no network services exported, no NFS -more secure service-wise than 3 -RH has network here, although they claim that 2 is not used 3 full multi-user -direct boot without X is useful if X breaks the console for some reason, more comfortable to work with than 1 4 as 3 but reserved for local use 5 full multi-user + X -goes hand in hand with 3 I don't understand why the next-gen init would have problems with a setup like this.. If it uses dependencies, supporting a scheme like this shouldn't be a problem, no? As with anything in Debian, it really depends on how much muscle is put into it. Hopefully so.. t:T ___/Timo Aaltonen http://users.tkk.fi/~tjaalton Work: HUT/CC, GSM +358-50-5918781 (work) / +358-40-5549618 (personal) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Scripsit Timo Aaltonen [EMAIL PROTECTED] 2 multi-user, no network services exported, no NFS -more secure service-wise than 3 -RH has network here, although they claim that 2 is not used Given that it is very rare for machines these days to have banks of local ttys attached, is a multi-user without network runlevel really relevant for even a significant minory of our users? How would those multiple users interact with the machine? Or does it mean single non-root user? -- Henning Makholm Monarki, er ikke noget materielt ... Borger! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
* Henning Makholm [EMAIL PROTECTED] [2005-08-15 13:17:02]: Scripsit Timo Aaltonen [EMAIL PROTECTED] 2 multi-user, no network services exported, no NFS -more secure service-wise than 3 -RH has network here, although they claim that 2 is not used Given that it is very rare for machines these days to have banks of local ttys attached, is a multi-user without network runlevel really relevant for even a significant minory of our users? How would those multiple users interact with the machine? My workstation has two heads, with independent Xservers, one for me and one for my wife. The number of heads is limited by the number of PCI/AGP video cards you can use. The linuxconsole project works on a kernel patch that makes this more mainstream. three(?) commercial companies are selling such solutions. But you are right that both my wife and I think that without network the box is utterly booring. signature.asc Description: Digital signature
Re: runlevels remodeled
On Mon, Aug 15, 2005 at 02:16:30PM +0200, Andreas Schuldei wrote: My workstation has two heads, with independent Xservers, one for me and one for my wife. The number of heads is limited by the number of PCI/AGP video cards you can use. The linuxconsole project works on a kernel patch that makes this more mainstream. How do you make this work? Last time I tried it, X would only show the one connected to the “active” virtual console, and blanked the other. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
On Mon, 15 Aug 2005, Henning Makholm wrote: Scripsit Timo Aaltonen [EMAIL PROTECTED] 2 multi-user, no network services exported, no NFS -more secure service-wise than 3 -RH has network here, although they claim that 2 is not used Given that it is very rare for machines these days to have banks of local ttys attached, is a multi-user without network runlevel really relevant for even a significant minory of our users? How would those multiple users interact with the machine? Or does it mean single non-root user? Well, I've given some thought on what LSB means by multiuser with no network services exported, and I believe it means that network is up, but no network services are yet started. This is how Redhat works (tried to check SuSE but the documentation was one 69MB download...). I admit that a machine without network is of little use, but one that you can be certain does not have any open ports is in some scenarios useful.. t -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Scripsit Timo Aaltonen [EMAIL PROTECTED] On Mon, 15 Aug 2005, Henning Makholm wrote: Given that it is very rare for machines these days to have banks of local ttys attached, is a multi-user without network runlevel really relevant for even a significant minory of our users? How would those multiple users interact with the machine? Well, I've given some thought on what LSB means by multiuser with no network services exported, and I believe it means that network is up, but no network services are yet started. This is how Redhat works Still, without any network services started it will be difficult for the multiple users to interact with the box. No sshd, no telnetd, etc ... how do the multiple users get in? I admit that a machine without network is of little use, but one that you can be certain does not have any open ports is in some scenarios useful.. I agree that it could be useful for maintenance situations where one wants apt-get to be able to download stuff. But it sounds like single user with network would be a more honest description than multi-user without network services. -- Henning Makholm Hele toget raslede imens Sjælland fór forbi.
Re: runlevels remodeled
Henning Makholm wrote: Given that it is very rare for machines these days to have banks of local ttys attached, is a multi-user without network runlevel really relevant for even a significant minory of our users? How would those multiple users interact with the machine? Timo Aaltonen writes: I admit that a machine without network is of little use... Bringing the machine up without networking can be useful for problem solving. I prefer to use multiple consoles when doing so. This requires multiuser. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Scripsit John Hasler [EMAIL PROTECTED] Bringing the machine up without networking can be useful for problem solving. I prefer to use multiple consoles when doing so. This requires multiuser. Perhaps I'm just missing some specific technical definition of multiuser, but what you describe sounds like single user, multitasking. -- Henning Makholm ... not one has been remembered from the time when the author studied freshman physics. Quite the contrary: he merely remembers that such and such is true, and to explain it he invents a demonstration at the moment it is needed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
On Monday 15 August 2005 07:45 am, John Hasler wrote: Bringing the machine up without networking can be useful for problem solving. I prefer to use multiple consoles when doing so. This requires multiuser. You can also use openvt(1) in single-user mode. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Whoever created the human body left in a fairly basic | | design flaw. It has a tendency to bend at the knees. | | -- Terry Pratchett, _Men at Arms_ | \ The Turtle Moves! -- http://www.lspace.org ---/ pgp6oFioiwoq4.pgp Description: PGP signature
Re: runlevels remodeled
On Fri, 12 Aug 2005, John Hasler wrote: Henrique de Moraes Holschuh writes: If the local admin needs multiple multi-user runlevels, he can always set it up himself (and use a initscript system that supports it without hassle ;-) ), Could you suggest one? file-rc or sysv-rc :-) Both will work just fine with multiple multi-user runlevels. -- 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: runlevels remodeled
On Fri, Aug 12, 2005 at 03:52:50PM +, Miquel van Smoorenburg wrote: Yes, all mounts from fstab, including NFS mounts, are done in single user mode. But you should only put essential,static mounts in /etc/fstab (say, /usr or so). For the rest you should use automount. The NFS volumes should always be mounted during normal operation (there are system services using data on NFS) so they satisfy both the essential and static criteria. Automount would be just unneccessary bloat. Also there were a couple of situations when I'd preferred if single-user mode did not try to mount /home or /var even if they were just regular local file systems. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
On Fri, Aug 12, 2005 at 05:25:51PM +0200, GOMBAS Gabor wrote: On Fri, Aug 12, 2005 at 04:05:43PM +0300, Timo Aaltonen wrote: Single-user mode is a fiasco, because in /etc/rcS.d/* there are a number of services that really should not belong there. Examples: -network -all disks (including NFS) mounted Well, I have no strong feelings without the multiuser levels, but starting NFS in single user mode is a _major_ PITA. I really-really hated Debian for this when I was administering NFS-using computers. For example, the Solaris way (just do enough to be able to launch /bin/sh, and leave everything else to the admin) is much more useful in practice. You get that behaviour if you boot emergency mode instead of single user. (You can't switch to it from multi-user mode though.) In my experience emergency mode tends to be more useful than single user. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
On Sat, 13 Aug 2005, Hamish Moffatt wrote: You get that behaviour if you boot emergency mode instead of single user. (You can't switch to it from multi-user mode though.) In my experience emergency mode tends to be more useful than single user. Same, here. Debian rc.S does too much IMHO. However, emergency mode is a major pain to even shutdown the system afterwards. It is really not supposed to be used as the usual I need this fucking thing in a clean state without anything running and depending on nothing but itself (no network crap) to do some work single-user mode. -- 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: runlevels remodeled
Hamish Moffatt wrote: You get that behaviour if you boot emergency mode instead of single user. If by emergency mode you mean init=/bin/sh, then doing: exec /sbin/init will continue the boot, I'm pretty sure. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
On Sat, Aug 13, 2005 at 05:04:19PM -0400, Anthony DeRobertis wrote: Hamish Moffatt wrote: You get that behaviour if you boot emergency mode instead of single user. If by emergency mode you mean init=/bin/sh, then doing: exec /sbin/init will continue the boot, I'm pretty sure. No, sysvinit has a real emergency mode; boot with emergency on the kernel command line. On Debian it will run sulogin to ask for the root password, then dump you into a shell. No networking, only root mounted (read-only), etc. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
In article [EMAIL PROTECTED] you wrote: If by emergency mode you mean init=/bin/sh, then doing: exec /sbin/init will continue the boot, I'm pretty sure. Emergency mode is specifying -b or emergency at the kernel boot prompt. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Does there exist a list of all the packages that install scripts in /etc/init.d? -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
On Aug 14, John Hasler [EMAIL PROTECTED] wrote: Does there exist a list of all the packages that install scripts in /etc/init.d? Yes, it's called Contents-$ARCH.gz... -- ciao, Marco signature.asc Description: Digital signature
Re: runlevels remodeled
On Sunday 14 August 2005 02:55, Marco d'Itri wrote: On Aug 14, John Hasler [EMAIL PROTECTED] wrote: Does there exist a list of all the packages that install scripts in /etc/init.d? Yes, it's called Contents-$ARCH.gz... You mean: http://packages.debian.org/cgi-bin/search_contents.pl?word=%2Fetc%2Finit.dsearchmode=searchfilesanddirscase=insensitiveversion=unstablearch=i386 ? pgp2bqFPvh5QM.pgp Description: PGP signature
Re: runlevels remodeled
I wrote: Does there exist a list of all the packages that install scripts in /etc/init.d? Marco writes: Yes, it's called Contents-$ARCH.gz... Thanks. That gives me some of what I need. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Frans Pop writes: You mean: http://packages.debian.org/cgi-bin/search_contents.pl?word=%2Fetc%2Finit.dsearchmode=searchfilesanddirscase=insensitiveversion=unstablearch=i386 ? That's more useful: it gets me quickly to the short descriptions. (I thought that the Debian site search was still broken.) -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
[Timo Aaltonen] Single-user mode is a fiasco, because in /etc/rcS.d/* there are a number of services that really should not belong there. Examples: -network -all disks (including NFS) mounted ..and those that depend on them. Yes, singleuser in debian is not working very well. I expect 'telinit s' to bring me to a state where I can umount /usr/ without much hassle. Debian does not work in that regard. Running daemons keep running when moving to single user mode. So, to correct that the runlevels would look roughly like this: (S-as now, services that are needed by all runlevels (except 0,6 of course), most stuff after S30 moved to 2-5) 1 -single-user, only the rootfs mounted 2 -multi-user, all local disks mounted, no network 3 -multi-user + network 4 -multi-user + network 5 -multi-user + network + X Looks fairly good to me. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Quoting Timo Aaltonen [EMAIL PROTECTED]: Is there will to change the current policy regarding runlevels in Debian? I'd propose to use the recommendation made by LSB: IIRC, there were discussions about that issue. I don't remember the outcome and would like to see Debian more LSBish here. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Hi, Timo Aaltonen wrote: Is there will to change the current policy regarding runlevels in Debian? I'd propose to use the recommendation made by LSB: I'd counterpropose to make this optional. I very much like the fact that the runlevels have no default meaning and would prefer it to stay that way, although I can see the issue of LSB compliance. Simon signature.asc Description: OpenPGP digital signature
Re: runlevels remodeled
On Fri, 12 Aug 2005, Timo Aaltonen wrote: Is there will to change the current policy regarding runlevels in Debian? I'd propose to use the recommendation made by LSB: Well, for what is it worth, I am against part of what you describe. We can shuffle what happens in system init (rc.S), single user and multi-user runlevel of course, but *PLEASE* do not add multiple multi-user runlevels on top of it. The reason is simple. Multiple multi-user runlevels are a major pain to support _by default_ _at the same time_ in _all_ next-generation-style initscript systems, and they are of very limited use anyway (otherwise we would have been pressured into adding them to Debian a few years ago). If the local admin needs multiple multi-user runlevels, he can always set it up himself (and use a initscript system that supports it without hassle ;-) ), and Debian packages won't screw with his configuration later (that would be a grave/critical bug :P ). Single-user mode is a fiasco, because in /etc/rcS.d/* there are a number of services that really should not belong there. Examples: -network -all disks (including NFS) mounted THAT can be changed orthogonally to adding more multi-user runlevels, and IMHO it is something we can rethink, alright. -- 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: runlevels remodeled
[Simon Richter] I'd counterpropose to make this optional. I very much like the fact that the runlevels have no default meaning and would prefer it to stay that way, although I can see the issue of LSB compliance. Care to share with us on why you like the current setup? Personally, I hate that it isn't a standardized way to get down to a minimal system, or a standardized way to start everything bug *dm/X. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Timo Aaltonen writes: Is there will to change the current policy regarding runlevels in Debian? I'd propose to use the recommendation made by LSB: Please check the archives. This has been discussed many times. It is clear that there is going to be no change. I've been considering adding a feature to sysvconfig to configure LSB runlevels. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Henrique de Moraes Holschuh writes: If the local admin needs multiple multi-user runlevels, he can always set it up himself (and use a initscript system that supports it without hassle ;-) ), Could you suggest one? -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
On Fri, Aug 12, 2005 at 04:05:43PM +0300, Timo Aaltonen wrote: Single-user mode is a fiasco, because in /etc/rcS.d/* there are a number of services that really should not belong there. Examples: -network -all disks (including NFS) mounted Well, I have no strong feelings without the multiuser levels, but starting NFS in single user mode is a _major_ PITA. I really-really hated Debian for this when I was administering NFS-using computers. For example, the Solaris way (just do enough to be able to launch /bin/sh, and leave everything else to the admin) is much more useful in practice. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
On Fri, Aug 12, 2005 at 04:23:04PM +0200, Petter Reinholdtsen wrote: Personally, I hate that it isn't a standardized way to get down to a minimal system, or a standardized way to start everything bug *dm/X. I do not think that X should be anything special. Yes, there is the case when you have X misconfigured and you have crappy hardware so you cannot go back to text mode after X has started; but this could be handled in a more generic way by introducing interactive startup where the startup script of every service asks if it should be started or not. That would be much more useful than a new run level. There is a similar argument for networking: there are cases when being able not to start networking is good but this could also be addressed by an interactive startup without a new run level. (Well, if you implement interactive startup using a new run level, that I would definitely support.) Not being able to cleanly go down to single-user is another matter which can be considered as a normal bug. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
On Fri, Aug 12, 2005 at 09:52:38AM -0500, John Hasler wrote: Timo Aaltonen writes: Is there will to change the current policy regarding runlevels in Debian? I'd propose to use the recommendation made by LSB: Please check the archives. This has been discussed many times. It is clear that there is going to be no change. The last sentence is not true. For some of the compelling reasons as to why this should change please review the last time we discussed this [0] (when I brought the issue up in my TODO stuff for etch [1]). As with anything in Debian, it really depends on how much muscle is put into it. Regards Javier [0] Thread starts due to Andrew's objection to that change http://lists.debian.org/debian-devel/2005/06/msg00551.html [1] Currently at http://wiki.debian.net/?EtchTODOList and http://wiki.debian.net/?EtchWishList signature.asc Description: Digital signature
Re: runlevels remodeled
In article [EMAIL PROTECTED], GOMBAS Gabor [EMAIL PROTECTED] wrote: On Fri, Aug 12, 2005 at 04:05:43PM +0300, Timo Aaltonen wrote: Single-user mode is a fiasco, because in /etc/rcS.d/* there are a number of services that really should not belong there. Examples: -network -all disks (including NFS) mounted Well, I have no strong feelings without the multiuser levels, but starting NFS in single user mode is a _major_ PITA. I really-really hated Debian for this when I was administering NFS-using computers. NFS isn't started in single user mode. Yes, all mounts from fstab, including NFS mounts, are done in single user mode. But you should only put essential,static mounts in /etc/fstab (say, /usr or so). For the rest you should use automount. For example, the Solaris way (just do enough to be able to launch /bin/sh, and leave everything else to the admin) is much more useful in practice. If you don't want NFS mounts in single user mode, don't put them in /etc/fstab ... Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
[Miquel van Smoorenburg] If you don't want NFS mounts in single user mode, don't put them in /etc/fstab ... Your simple solution do not match all installation. For those installation with NFS mounts in fstab and no automount setting, it would be useful with a singleuser mode without mounting of these NFS mounts (I get the impression that you want to be read as an authority on the subject. I'm not sure you succeed. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
I wrote: Please check the archives. This has been discussed many times. It is clear that there is going to be no change. Javier writes: The last sentence is not true. For some of the compelling reasons as to why this should change... I didn't say it shouldn't change. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
