Re: Debian, daemons and runlevels (was: Re: X and runlevels)
On Mon, Sep 04, 2000 at 10:28:20AM -0300, Henrique M Holschuh wrote: I was going to tack this sooner or later (the trust us, we KNOW you want the daemons to start always current state of almost all daemon packages annoys me to no end, and from past flamewars I know I'm not the only one), I think I even warned a few newbies in -user two days ago about this :-) it is a reasonable assumption to make - if someone installs a package then it is almost certain that they want it to run, not just sit there and take up disk space. the tiny minority who want to install but not run a package can take whatever special steps are needed to achieve their non-standard configuration. The solution is to *force* all daemon packages to never start a daemon out of its intended runlevel, be it during first install or upgrades (I think this probably requires a policy change). I'd even say this should be a goal for woody, unless we're going to try to get woody out of the door very fast. this sounds bloody annoying. if you don't want a service to start, then don't install the package. simple, really. if for some reason (e.g. transitional dependancies like netbase portmap) you have the package installed, and still don't want the service to start then use update-rc.d to modify the run-level symlinks (or modify them by hand). and, as ever, after an upgrade you should thoroughly check your system to make sure that everying is running (or not running as the case may be) exactly as you intend it. take appropriate action when you encounter any divergence from your desires. no package manager can read your mind. you're still going to have to do some of the work yourself. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, daemons and runlevels (was: Re: X and runlevels)
On Thu, 07 Sep 2000, Craig Sanders wrote: On Mon, Sep 04, 2000 at 10:28:20AM -0300, Henrique M Holschuh wrote: I was going to tack this sooner or later (the trust us, we KNOW you want the daemons to start always current state of almost all daemon packages annoys me to no end, and from past flamewars I know I'm not the only one), I think I even warned a few newbies in -user two days ago about this :-) it is a reasonable assumption to make - if someone installs a package Yes, it is. But it is just that: an assumption. That's all we can do right now for package installs, and it CAN be argued that it's all we should ever do in package installs. My current issue is with package upgrades. So, please, let's not even get into the 'start daemons at package install' issue right now. Let me tack the upgrade problem first, and when that's done and ready (please note I didn't say accepted), we can move to the install problem and we can argue all you want about it. Here is what I'm trying to fix: Upgrading a daemon while the system is in runlevel 4 and the init script system is set up to stop that daemon in runlevel 4 is a *bug*. If you call the script which addresses the upgrade issue during installs as well, it won't malfunction (this is a design requirement), and you can share the same code for upgrades and installs. It *could* be used to avoid starting a daemon during installs if extended to do so, but it doesn't _have_ to. The solution is to *force* all daemon packages to never start a daemon out of its intended runlevel, be it during first install or upgrades (I think this probably requires a policy change). I'd even say this should be a goal for woody, unless we're going to try to get woody out of the door very fast. this sounds bloody annoying. If everyone had to write a lot of complicated code to get this to work, I'd agree with you. As it stands, I'm writing all the code needed for sysvinit, and I could even try to do the same for file-rc after the sysvinit code is ready, tested, published to -devel and ripped to shreds. A *design* goal in this stuff is that: If you do nothing to the defaults, the system will act just like it does today. In *all* cases, even the highly unlikely ones such as no init system at all being installed. You as a maintainer will have to add something that boils down to: ... update-rc.d foo bar foobar barfoo +if canIstartTheDaemonPlease daemonname; then + /etc/init.d/daemoname start +fi ... After all error checking is stripped off. if you don't want a service to start, then don't install the package. simple, really. As I said, let's leave that issue alone for now, please. [...] no package manager can read your mind. you're still going to have to do It doesn't need to, I consider the start on upgrade as it stands a bug because the system can detect what it should do, unless I am overlooking something... which is why I'm trying to get the code done and working before posting anything else to -devel. -- 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 pgpT619SC1RjZ.pgp Description: PGP signature
Re: Debian, daemons and runlevels (was: Re: X and runlevels)
On Wed, Sep 06, 2000 at 10:01:31PM -0300, Henrique M Holschuh wrote: Here is what I'm trying to fix: Upgrading a daemon while the system is in runlevel 4 and the init script system is set up to stop that daemon in runlevel 4 is a *bug*. ok, this makes sense. i must have misunderstood what you were saying. i agree with the above. You as a maintainer will have to add something that boils down to: ... update-rc.d foo bar foobar barfoo +if canIstartTheDaemonPlease daemonname; then + /etc/init.d/daemoname start +fi ... After all error checking is stripped off. fine, sounds good. i have no problem at all with that. quite the opposite, in fact. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, daemons and runlevels (was: Re: X and runlevels)
On Wed, 06 Sep 2000, Henrique M Holschuh wrote: Here is what I'm trying to fix: Upgrading a daemon while the system is in runlevel 4 and the init script system is set up to stop that daemon in runlevel 4 is a *bug*. Damn, I should have said Starting a daemon in a upgrade while the system... -- 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 pgpixNxrN6eTz.pgp Description: PGP signature
Re: X and runlevels
On Tue, Sep 05, 2000 at 11:01:28AM +0200, Marcelo E. Magallon wrote: Branden Robinson [EMAIL PROTECTED] writes: and sent patches to XFree86 a long time ago, but the patch was ignored, and Dirk Hohndel basically told me I was an idiot for doing so, because it might unexpectedly terminate the server in the quite common case of four X session logins in a row that averaged less than 6 seconds each... Huh all right. I don't understand what you/he meant by that, but the code that was patched (the xdm shipped with 3.3.2) was broken. No it wasn't. After I started shipping our xdm packages with those resources switched on our problems with xdm loops forever and I can't log in as root on the console to turn it off went away. This is not because everybody suddenly learned how to type CTRL-R; that would require reading the manaual. The patch worked based on the *number* of consecutive failures. The current code works based on the *time* between failures, and it's rather agressive at that IMO. I've seen a little bit of the current (4.0.1) behavior and I think it's badly broken. I haven't had time to examine it. -- G. Branden Robinson | It doesn't matter what you are doing, Debian GNU/Linux| emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://www.debian.org/~branden/ | pgpxlrjhsqDTE.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 10:32:07AM +0200, Per Lundberg wrote: How come Debian don't have a non-X runlevel, like some other distributions, in the default configuration? I think this would be pretty convenient. Because no one has ever bothered to write a runlevel policy. -- G. Branden Robinson | Debian GNU/Linux| If existence exists, [EMAIL PROTECTED] | why create a creator? http://www.debian.org/~branden/ | pgpAPdxG0OxxJ.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 02:51:46PM +0200, Paul Slootman wrote: Actually, that used to be a problem (I've had that as well, where an incorrectly configured X e.g. for a different card caused an infinite loop of switching to X and back again, so that you never have the chance of switching with alt-ctrl-F1 and staying there). Nowadays xdm detects that the X server is looping, and after a couple of times stops restarting the X server. This has saved me once or twice. Thanks, Branden! (or was it someone else's work?) The code to do this has existed in xdm for a very long time, but XFree86 always shipped with it turned off. I turned it back on (it just involves a few resource settings for the display manager, see the xdm manpage), and sent patches to XFree86 a long time ago, but the patch was ignored, and Dirk Hohndel basically told me I was an idiot for doing so, because it might unexpectedly terminate the server in the quite common case of four X session logins in a row that averaged less than 6 seconds each... If you're saying, Huh? right about now, that's okay, because I did too. -- G. Branden Robinson | Experience should teach us to be most on Debian GNU/Linux| our guard to protect liberty when the [EMAIL PROTECTED] | government's purposes are beneficent. http://www.debian.org/~branden/ | -- Louis Brandeis pgpLog5Lv6r1L.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 04:43:44PM -0500, Branden Robinson wrote: The code to do this has existed in xdm for a very long time, but XFree86 always shipped with it turned off. I turned it back on (it just involves a few resource settings for the display manager, see the xdm manpage), and sent patches to XFree86 a long time ago, but the patch was ignored, and Dirk Hohndel basically told me I was an idiot for doing so, because it might unexpectedly terminate the server in the quite common case of four X session logins in a row that averaged less than 6 seconds each... If you're saying, Huh? right about now, that's okay, because I did too. No, I can understand that. - that exact circumstance would occur in our University computer science lab. Regularly too, I might add. -- Michael Beattie ([EMAIL PROTECTED]) - Games? Did someone say games? -- Q - Debian GNU/Linux Ooohh You are missing out! pgpTYHvnXdZkM.pgp Description: PGP signature
Re: X and runlevels
On Tue, Sep 05, 2000 at 09:57:56AM +1200, Michael Beattie wrote: On Mon, Sep 04, 2000 at 04:43:44PM -0500, Branden Robinson wrote: Dirk Hohndel basically told me I was an idiot for doing so, because it might unexpectedly terminate the server in the quite common case of four X session logins in a row that averaged less than 6 seconds each... If you're saying, Huh? right about now, that's okay, because I did too. No, I can understand that. - that exact circumstance would occur in our University computer science lab. Regularly too, I might add. I take it this is LART-worthy incident, as I don't think I can load my .xsession in under 6 seconds. Since *dm requires you get a username and password (bwahaahaa!), use it. -- David Starner - [EMAIL PROTECTED] http/ftp: dvdeug.dhis.org It was starting to rain on the night that they cried forever, It was blinding with snow on the night that they screamed goodbye. - Dio, Rock and Roll Children -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000 at 05:05:09PM -0500, David Starner wrote: No, I can understand that. - that exact circumstance would occur in our University computer science lab. Regularly too, I might add. I take it this is LART-worthy incident, as I don't think I can load my .xsession in under 6 seconds. Since *dm requires you get a username and password (bwahaahaa!), use it. yeah, I'll LART you... lab == lots of people == lots of NCD xterms == lots of quick logins to the DEC Unix server at the beginning of a lab... sheesh -- Michael Beattie ([EMAIL PROTECTED]) - Bother, said Pooh, as he heard, Will the Defendant please rise. - Debian GNU/Linux Ooohh You are missing out! pgpvlM500Al5O.pgp Description: PGP signature
Re: X and runlevels
On Mon, 04 Sep 2000, Branden Robinson wrote: On Mon, Sep 04, 2000 at 10:32:07AM +0200, Per Lundberg wrote: How come Debian don't have a non-X runlevel, like some other distributions, in the default configuration? I think this would be pretty convenient. Because no one has ever bothered to write a runlevel policy. Well, we might end up inheriting the one from LSB if Debian decides to try to follow as much as possible of it, but it's not like we need to get concerned with implementing it yet. What we must ensure is that Debian will work right with whatever runlevel scheme the local administrator comes up with and sets the system up with. After this is done, implementing whatever runlevel policy we want is a simple matter of a mass change of the update-rc.d invocations in a great deal of packages ;-) -- 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 pgpL68Tmp4HFg.pgp Description: PGP signature
Re: X and runlevels
On Tue, Sep 05, 2000 at 09:57:56AM +1200, Michael Beattie wrote: On Mon, Sep 04, 2000 at 04:43:44PM -0500, Branden Robinson wrote: The code to do this has existed in xdm for a very long time, but XFree86 always shipped with it turned off. I turned it back on (it just involves a few resource settings for the display manager, see the xdm manpage), and sent patches to XFree86 a long time ago, but the patch was ignored, and Dirk Hohndel basically told me I was an idiot for doing so, because it might unexpectedly terminate the server in the quite common case of four X session logins in a row that averaged less than 6 seconds each... If you're saying, Huh? right about now, that's okay, because I did too. No, I can understand that. - that exact circumstance would occur in our University computer science lab. Regularly too, I might add. Eh? With no gaps between? Remember, the X server is running even if it's idling at the X server login widget. That factors into the 6 second average. -- G. Branden Robinson| I came, I saw, she conquered. The Debian GNU/Linux | original Latin seems to have been [EMAIL PROTECTED] | garbled. http://deadbeast.net/~branden/ | -- Robert Heinlein pgpI2By1OT41a.pgp Description: PGP signature
Re: X and runlevels
On Tue, Sep 05, 2000 at 10:25:23AM +1200, Michael Beattie wrote: On Mon, Sep 04, 2000 at 05:05:09PM -0500, David Starner wrote: No, I can understand that. - that exact circumstance would occur in our University computer science lab. Regularly too, I might add. I take it this is LART-worthy incident, as I don't think I can load my .xsession in under 6 seconds. Since *dm requires you get a username and password (bwahaahaa!), use it. yeah, I'll LART you... lab == lots of people == lots of NCD xterms == lots of quick logins to the DEC Unix server at the beginning of a lab... sheesh Quick logins don't trigger the termination of the server. It's a login, followed by an immediate logout, followed by an immedate login, repeat 4 times, that causes it. -- G. Branden Robinson | You don't just decide to break Kubrick's Debian GNU/Linux| code of silence and then get drawn away [EMAIL PROTECTED] | from it to a discussion about cough http://www.debian.org/~branden/ | medicine. pgp0wR1ibnwC6.pgp Description: PGP signature
Re: X and runlevels
John Hasler [EMAIL PROTECTED] wrote:
a) You just made some changes in X that caused it to lock up the display.
Magic sysreq got you out alive, but now you would like to boot to a
console to fix it.
b) Your monitor blew up. You've got a replacement on hand, but it won't
work (and may even be damaged) with the current X settings.
Single user mode.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000 at 07:36:00PM -0500, Branden Robinson wrote: lab == lots of people == lots of NCD xterms == lots of quick logins to the DEC Unix server at the beginning of a lab... sheesh Quick logins don't trigger the termination of the server. It's a login, followed by an immediate logout, followed by an immedate login, repeat 4 times, that causes it. Okay, my error, I was under the impression that it was fast spawning of whatever it is that supplies the display to a client. -- Michael Beattie ([EMAIL PROTECTED]) - From a 1996 MicroSloth ad campaign: The less you know about computers the more you want MicroSoft! -- See! They do get some things right! (I gotta stop stealing Sigs) - Debian GNU/Linux Ooohh You are missing out! pgp8r84lmI67r.pgp Description: PGP signature
Re: X and runlevels
[you don't have to CC me on messages to debian-devel] On Tue, Sep 05, 2000 at 01:49:26PM +1200, Michael Beattie wrote: On Mon, Sep 04, 2000 at 07:36:00PM -0500, Branden Robinson wrote: lab == lots of people == lots of NCD xterms == lots of quick logins to the DEC Unix server at the beginning of a lab... sheesh Quick logins don't trigger the termination of the server. It's a login, followed by an immediate logout, followed by an immedate login, repeat 4 times, that causes it. Okay, my error, I was under the impression that it was fast spawning of whatever it is that supplies the display to a client. No, xdm only pays attention to having to invoke the server binary: spawn X server toss up login widget user logs in login widget is killed user session starts user session dies, cores, whatever server exits Rinse. Repeat. -- G. Branden Robinson| Communism is just one step on the long Debian GNU/Linux | road from capitalism to capitalism. [EMAIL PROTECTED] | -- Russian saying http://deadbeast.net/~branden/ | pgp4OGUHf1OWa.pgp Description: PGP signature
Re: X and runlevels
On 04 Sep 2000, Brian Mays [EMAIL PROTECTED] wrote: Not quite. The FHS briefly mentions *System V's* runlevel 2 and 3 (along with Berkley's multiuser state). It does not specify anything about runlevels for Linux or any other OS. O.k., you're right - it was on linuxbase.org. Which we support, according to their main-page. And there is this linked from there: http://www.debian.org/Lists-Archives/lsb-spec-9904/msg5.html .- quote - | --- start of cut text -- | 0 halt | 1 single user mode | 2 multiuser with no remote networking | 3 normal/full multiuser | 4 reserved for local use, default is normal/full multiuser | 5 xdm or equivalent | 6 reboot | --- end `- quote - So, I'm asking, why we don't follow this guidelines? I don't see any contradiction with our current approach to leave it up to the user. That won't interfer IMHO, for the update-rc script (or what ever it's called) doesn't touch the links if any of them exists, right? So the user can still change 'em to her/his likes. Now, are we part of the linuxbase-project or aren't we? I know that it's not good to take everything without asking it - but the current setup is somewhat nonsense to me - 4 runlevels with the same setup Just a thought. Alfie -- Die meisten Menschen pflegen im Kindesalter vom Zeigen auf Gegenstände (Mausbewegung) und ga sagen (Mausklick) abzukommen, zugunsten eines mächtigeren und langwierig zu erlernenden Tools (Sprache). -- Achim Linder in de.comp.os.linux.misc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
Branden Robinson [EMAIL PROTECTED] writes: and sent patches to XFree86 a long time ago, but the patch was ignored, and Dirk Hohndel basically told me I was an idiot for doing so, because it might unexpectedly terminate the server in the quite common case of four X session logins in a row that averaged less than 6 seconds each... Huh all right. I don't understand what you/he meant by that, but the code that was patched (the xdm shipped with 3.3.2) was broken. In fact, the current code in 4.0.1 has been heavily patched to *enable* this functionality. No idea when that happend, sometime between 6.3 and 6.4 it would seem, and AFAICS, it was patched up-upstream, not by xfree86. The patch worked based on the *number* of consecutive failures. The current code works based on the *time* between failures, and it's rather agressive at that IMO. Amazed, Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On 04 Sep 2000, Brian Mays [EMAIL PROTECTED] wrote: Not quite. The FHS briefly mentions *System V's* runlevel 2 and 3 (along with Berkley's multiuser state). It does not specify anything about runlevels for Linux or any other OS. Gerfried Fuchs [EMAIL PROTECTED] replied: O.k., you're right - it was on linuxbase.org. Which we support, according to their main-page. ... So, I'm asking, why we don't follow this guidelines? Hmm ... Have you actually read the Linux Standard Base Specification? There's not much there; they have hardly fleshed out any of the specification. Personally, I hope that the impact of the whole LSB project on Debian will be a few minor changes and that most of the facilities required to be LSB compatible can be supplied by a single lsb Debian package. That is a long way down the road, however. I don't see any contradiction with our current approach to leave it up to the user. That won't interfere IMHO, for the update-rc script (or what ever it's called) doesn't touch the links if any of them exists, right? So the user can still change 'em to her/his likes. Go ahead and make a proposal that we adopt a particular runlevel scheme. Then the developers can vote on it. It is true that the update-rc script will still allow the system administrator to customize the links to his or her own needs. Now, are we part of the linuxbase-project or aren't we? I know that it's not good to take everything without asking it - but the current setup is somewhat nonsense to me - 4 runlevels with the same setup Not really. Some of our members are providing input into the project, but the LSB project doesn't have enough of a standard yet to adhere to, even if we wanted to adhere to it. - Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
X and runlevels
(Sorry if this has been discussed earlier, and/or this is the wrong list...) How come Debian don't have a non-X runlevel, like some other distributions, in the default configuration? I think this would be pretty convenient. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000 at 10:32:07AM +0200, Per Lundberg wrote: (Sorry if this has been discussed earlier, and/or this is the wrong list...) How come Debian don't have a non-X runlevel, like some other distributions, in the default configuration? I think this would be pretty convenient. perhaps because in the default configuration there is no display manager, and thus no automatic runage of X. also debian believes in leaving the runlevel configuration to the admin to define. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpIC6edoyEDt.pgp Description: PGP signature
Re: X and runlevels
EB == Ethan Benson [EMAIL PROTECTED] writes: EB perhaps because in the default configuration there is no EB display manager, and thus no automatic runage of X. Sure. But whenever you install something that gets you a display manager, your system will boot up in X. To get it to boot up in console mode, you have to manually remove the symlinks in your runlevel's script directory. The next time you update the display manager, you'll have to do this again. It is not really convenient. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon 04 Sep 2000, Per Lundberg wrote: Sure. But whenever you install something that gets you a display manager, your system will boot up in X. To get it to boot up in console mode, you have to manually remove the symlinks in your runlevel's script directory. The next time you update the display manager, you'll have to do this again. It is not really convenient. Not quite, if you leave at least one symlink somewhere in the rc?.d directories, your config should be left alone (i.e. the symlinks won't be redone). See the update-rc.d manpage: : INSTALLING INIT SCRIPT LINKS :When run with either the defaults, start, or stop options, :update-rc.d makes links /etc/rcrunlevel.d/[SK]NNname :pointing to the script /etc/init.d/name, : :If any files /etc/rcrunlevel.d/[SK]??name already exist :then update-rc.d does nothing. This is so that the system :administrator can rearrange the links, provided that they :leave at least one link remaining, without having their :configuration overwritten. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000 at 11:30:06AM +0200, Per Lundberg wrote: EB == Ethan Benson [EMAIL PROTECTED] writes: EB perhaps because in the default configuration there is no EB display manager, and thus no automatic runage of X. Sure. But whenever you install something that gets you a display manager, your system will boot up in X. To get it to boot up in is that not what you wanted when you installed *dm ? console mode, you have to manually remove the symlinks in your runlevel's script directory. The next time you update the display manager, you'll have to do this again. It is not really convenient. no there not, the symlinks are only restored if ALL of them were removed (that is your removed the link from runlevel 0 - 6) and if you did that why not just apt-get --purge remove *dm ? at least that is how update-rc.d works on all 5 debian systems i work with. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpToRWUOqvmi.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 11:30:06AM +0200, Per Lundberg wrote: [...] To get it to boot up in console mode, you have to manually remove the symlinks in your runlevel's script directory. The next time you update the display manager, you'll have to do this again. It is not really convenient. Upgrading xdm should not affect the links in /etc/rc?.d as update-rc.d (called in the postinst) is a no-op if any links for the script already exist. Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9809 0133 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
EB == Ethan Benson [EMAIL PROTECTED] writes: Sure. But whenever you install something that gets you a display manager, your system will boot up in X. EB is that not what you wanted when you installed *dm ? Maybe, but having the option to get into console mode too would be nice. Sometimes, you might not want X to start up when you reboot. (I don't do this very often, but I know there are people that do) EB no there not, the symlinks are only restored if ALL of them EB were removed Are you *absolutely* sure? The reason I ask is because I've been having this exact problem with gpm lately. I like to start it occasionally, because it interfers with my X configuration, so I use to remove the symlinks. Each and every time gpm is updated (two times the last week), they have been brought back to life. Pretty annoying, if you ask me. (This is a woody system) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon 04 Sep 2000, Per Lundberg wrote: Are you *absolutely* sure? The reason I ask is because I've been Yes. having this exact problem with gpm lately. I like to start it occasionally, because it interfers with my X configuration, so I use to remove the symlinks. Each and every time gpm is updated (two times Don't remove _all_ the symlinks, leave the K ones. Or move one of the symlinks to rc5.d or whatever. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000 at 11:43:35AM +0200, Per Lundberg wrote: Maybe, but having the option to get into console mode too would be nice. Sometimes, you might not want X to start up when you reboot. (I don't do this very often, but I know there are people that do) the key is not everyone does it the same way, i personally used to, then realized i *NEVER* booted the system into a different runlevel to avoid X and quit bothering, i am fine with it. there are other software that i do tinker with the symlinks. (*cough* portmap) the thing is debian LETS me. it leaves the decision where it belongs with me. EB no there not, the symlinks are only restored if ALL of them EB were removed Are you *absolutely* sure? The reason I ask is because I've been /me checks, yup im sure. having this exact problem with gpm lately. I like to start it occasionally, because it interfers with my X configuration, so I use to remove the symlinks. Each and every time gpm is updated (two times the last week), they have been brought back to life. Pretty annoying, if you ask me. if that is true (and your only removing SOME of the symlinks not ALL of them) then its a bug and should be filed in the BTS. that is NOT how it is supposed to work. from the update-rc.d man page: If any files /etc/rcrunlevel.d/[SK]??name already exist then update-rc.d does nothing. This is so that the system administrator can rearrange the links, provided that they leave at least one link remaining, without having their configuration overwritten. (This is a woody system) i have a field of potatoes so maybe there is a new bug in woody. either that or gpm is being evil and making the symlinks itself instead of using update-rc.d like its supposed to. also you mean that the symlinks are recreated, not just gpm being restarted right? there is an obnoxious behavior in debian where upgraded packages are started even if they were not running in the first place. (*cough* portmap *cough*) there was a bit of discussion on fixing this but i don't know if its being worked on actively or not. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpGe0PalLsBj.pgp Description: PGP signature
Re: X and runlevels
EB == Ethan Benson [EMAIL PROTECTED] writes: EB it leaves the decision where it belongs with me. Yeah. I think you're right about this. I just got a little confused with my gpm problems, I guess. EB if that is true (and your only removing SOME of the symlinks EB not ALL of them) In fact, now when I think about it, I realise that I used update-rc.d to get rid of 'em. Sorry, I didn't know about that feature of update-rc.d. In fact, I think it could be argued that the postinst shouldn't recreate the links if the package was already installed. I mean, if they have been removed, it must be for a reason, right? But maybe a postinst script can't detect whether the package was already installed in a clean way? I don't know... EB also you mean that the symlinks are recreated, not just gpm EB being restarted right? I get both; and THIS is really annoying. It shouldn't be restarted if it wasn't running already. EB there was a bit of discussion on fixing this but i don't know EB if its being worked on actively or not. I hope it is. It's definitely a bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon 04 Sep 2000, Ethan Benson wrote: also you mean that the symlinks are recreated, not just gpm being restarted right? there is an obnoxious behavior in debian where upgraded packages are started even if they were not running in the first place. (*cough* portmap *cough*) there was a bit of discussion on fixing this but i don't know if its being worked on actively or not. Debhelper (and one of the other helper things) does this, if you don't call dh_installinit with the --no-restart-on-upgrade (or such) option. I guess the reasoning is that (a) you're upgrading in multiuser mode because debian lets you :-) (b) in multiuser mode the daemon was running. It's unfortunate that there's no easy way to find the current runlevel (the usual who -r from Solaris etc. doesn't work), otherwise this piece of code could be used: RL=`who -r` if [ -x /etc/rc$RC.d/S??$PKGNAME ]; then /etc/rc$RC.d/S??$PKGNAME start fi That's ignoring file-rc, unfortunately. Is there an easy way of determining whether a certain init.d script should be started in the current runlevel that works also with file-rc ? Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re[2]: X and runlevels
Hello Paul, Monday, September 04, 2000, 3:01:42 PM, you wrote: PS It's unfortunate that there's no easy way to find the current runlevel PS (the usual who -r from Solaris etc. doesn't work) /sbin/runlevel can be used to find the current runlevel -- Best regards, Michaelmailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On 4 Sep 00 09:43:35 GMT, Per Lundberg [EMAIL PROTECTED] wrote: EB == Ethan Benson [EMAIL PROTECTED] writes: Sure. But whenever you install something that gets you a display manager, your system will boot up in X. EB is that not what you wanted when you installed *dm ? Maybe, but having the option to get into console mode too would be nice. Sometimes, you might not want X to start up when you reboot. (I don't do this very often, but I know there are people that do) Isn't ctrl-alt-F[1-6] good enough to get into console mode? In what circumstances whould you not want X to start up on boot if you had installed a *dm? Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
[snip] Isn't ctrl-alt-F[1-6] good enough to get into console mode? In what circumstances whould you not want X to start up on boot if you had installed a *dm? In the circumstance when you are serving a flock of dumb clients from a single machine. NCD Xterms for example. In this case you *NEED* a *dm running with network access turned on but the machine itself may not even have a video. This setup is a small percentage of the installed base but it does exist and is used. [snip] -- Anton R. Ivanov ARI2-RIPE mailto:[EMAIL PROTECTED] IP Design Engineer, Global Architecture Level3 Communications The excuse for delaying today's deliverables is: emissions from GSM-phones /\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ pgpnYbyHOb20Q.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 12:48:24PM +0100, Anton Ivanov wrote: [snip] Isn't ctrl-alt-F[1-6] good enough to get into console mode? In what circumstances whould you not want X to start up on boot if you had installed a *dm? In the circumstance when you are serving a flock of dumb clients from a single machine. NCD Xterms for example. In this case you *NEED* a *dm running with network access turned on but the machine itself may not even have a video. This setup is a small percentage of the installed base but it does exist and is used. except this configuration has nothing to do with the runlevel links. you have to alter the configuration file for xdm or whatever to not manage a local X server, but you still need the daemon started at boot, by yes a initscript. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpN2K27doUer.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 11:30:06AM +0200, Per Lundberg wrote: Sure. But whenever you install something that gets you a display manager, your system will boot up in X. To get it to boot up in console mode, you have to manually remove the symlinks in your runlevel's script directory. The next time you update the display manager, you'll have to do this again. It is not really convenient. Alternatively, you could edit /etc/X11/xdm/Xservers (or its equivalent for other display managers) and disable the servers on the local display. xdm can still be used to manage remote sessions without running a local server. If you don't want to run xdm at all, why would you install it? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000, Per Lundberg wrote:
Are you *absolutely* sure? The reason I ask is because I've been
having this exact problem with gpm lately. I like to start it
occasionally, because it interfers with my X configuration
You might be interested in the `-R' option of gpm then.
Sam.
--
Samuel Hocevar [EMAIL PROTECTED]
http://www.via.ecp.fr/~sam/
1024D/29499F61 1999-04-221155 4B19 A50F 1136 6E60 A499 7CF3 F5AF 2949 9F61
dig goret.org @zoy.org axfr \
| perl -e 'for(sort()){print pack(H32,$1) if(/^c..\.(\w+)/)}' | gzip -d
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000 at 11:30:06AM +0200, Per Lundberg wrote: EB == Ethan Benson [EMAIL PROTECTED] writes: EB perhaps because in the default configuration there is no EB display manager, and thus no automatic runage of X. Sure. But whenever you install something that gets you a display manager, your system will boot up in X. To get it to boot up in console mode, you have to manually remove the symlinks in your runlevel's script directory. The next time you update the display manager, you'll have to do this again. It is not really convenient. I find commenting out the display line in /etc/X11/[xwg]dm/Xservers is sufficient. -- Michael Beattie ([EMAIL PROTECTED]) - Are the noises in my head bothering you? - Debian GNU/Linux Ooohh You are missing out! pgpCUwbmMjtHH.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 12:48:24PM +0100, Anton Ivanov wrote: In the circumstance when you are serving a flock of dumb clients from a single machine. NCD Xterms for example. In this case you *NEED* a *dm running with network access turned on but the machine itself may not even have a video. This setup is a small percentage of the installed base but it does exist and is used. Then disable the local display by commenting the server line in /etc/X11/xdm/Xservers -- Michael Beattie ([EMAIL PROTECTED]) - God's last name is not damn. - Debian GNU/Linux Ooohh You are missing out! pgpRRZu4gBgkU.pgp Description: PGP signature
Re: Re[2]: X and runlevels
On Mon 04 Sep 2000, Michael Bravo wrote: Monday, September 04, 2000, 3:01:42 PM, you wrote: PS It's unfortunate that there's no easy way to find the current runlevel PS (the usual who -r from Solaris etc. doesn't work) /sbin/runlevel can be used to find the current runlevel So it does. It just reads /var/run/utmp, like who does, so it should be trivial to add the -r flag to who :-) Thanks, Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000 at 12:48:24PM +0100, Anton Ivanov wrote: In the circumstance when you are serving a flock of dumb clients from a single machine. NCD Xterms for example. In this case you *NEED* a *dm running with network access turned on but the machine itself may not even have a video. This setup is a small percentage of the installed base but it does exist and is used. Then disable the local display by commenting the server line in /etc/X11/xdm/Xservers That is exactly what I have done. My fault. Should have described the setup in a bit more detail. The question I answered was what is the case when you need *dm and do not need X. It still does not answer the original question which was about X-only/ non-X runlevel. In other words how to boot in multiuser mode selectively with/without X. Which is quite a sensible question. Example: I had to go into an intermediate single user mode boot on some of my machines after forgetting to turn off xdm after changing video cards. Or during dealing with laptop docking gear. If there was a boot with X disabled and xdm installed it would have made life a bit easier. [snip] Cheers, Brgds, -- Anton R. Ivanov ARI2-RIPE mailto:[EMAIL PROTECTED] IP Design Engineer, Global Architecture Level3 Communications The excuse for delaying today's deliverables is: the real ttys became pseudo ttys and vice-versa. /\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On 04 Sep 2000, Ethan Benson [EMAIL PROTECTED] wrote: also debian believes in leaving the runlevel configuration to the admin to define. Sure - but there is the FHS (I hope that I read it there) that defines what at least runlevel 2 and 3 are for. I would really like to see that Debian complies with the FHS in that case, when it complies to it in the other meanings also, quite strict, even. Just a thought... Alfie -- Today is the tomorrow you worried about yesterday pgp0SgW8Mx9vM.pgp Description: PGP signature
Re: X and runlevels
Frank writes: Isn't ctrl-alt-F[1-6] good enough to get into console mode? In what circumstances whould you not want X to start up on boot if you had installed a *dm? a) You just made some changes in X that caused it to lock up the display. Magic sysreq got you out alive, but now you would like to boot to a console to fix it. b) Your monitor blew up. You've got a replacement on hand, but it won't work (and may even be damaged) with the current X settings. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon 04 Sep 2000, Anton Ivanov wrote: Example: I had to go into an intermediate single user mode boot on some of my machines after forgetting to turn off xdm after changing video cards. Or during dealing with laptop docking gear. If there was a boot with X disabled and xdm installed it would have made life a bit easier. Actually, that used to be a problem (I've had that as well, where an incorrectly configured X e.g. for a different card caused an infinite loop of switching to X and back again, so that you never have the chance of switching with alt-ctrl-F1 and staying there). Nowadays xdm detects that the X server is looping, and after a couple of times stops restarting the X server. This has saved me once or twice. Thanks, Branden! (or was it someone else's work?) Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000, Anton Ivanov wrote:
It still does not answer the original question which was about X-only/
non-X runlevel. In other words how to boot in multiuser mode selectively
with/without X. Which is quite a sensible question.
Example:
I had to go into an intermediate single user mode boot on some of
my machines after forgetting to turn off xdm after changing video cards.
Or during dealing with laptop docking gear.
If there was a boot with X disabled and xdm installed it would have
made life a bit easier.
I must admit I don't really understand the problem here. What
prevents you from going back to console mode ? Moreover, even if the X
server has a problem and keeps dying, startAttempts in xdm is set to 4
by default.
Sam.
--
Samuel Hocevar [EMAIL PROTECTED]
http://www.via.ecp.fr/~sam/
1024D/29499F61 1999-04-221155 4B19 A50F 1136 6E60 A499 7CF3 F5AF 2949 9F61
dig goret.org @zoy.org axfr \
| perl -e 'for(sort()){print pack(H32,$1) if(/^c..\.(\w+)/)}' | gzip -d
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
Paul Slootman schrieb: On Mon 04 Sep 2000, Ethan Benson wrote: Debhelper (and one of the other helper things) does this, if you don't call dh_installinit with the --no-restart-on-upgrade (or such) option. I guess the reasoning is that (a) you're upgrading in multiuser mode because debian lets you :-) (b) in multiuser mode the daemon was running. Running start-stop-daemon without --oknodo for restart) would probably also solve the problem (you do set -e, do you?). It would yell if it doesn't find the daemon running and exit. It's unfortunate that there's no easy way to find the current runlevel (the usual who -r from Solaris etc. doesn't work), otherwise this piece of code could be used: RL=`who -r` if [ -x /etc/rc$RC.d/S??$PKGNAME ]; then /etc/rc$RC.d/S??$PKGNAME start fi 14:27:10 [EMAIL PROTECTED]:~$ sudo runlevel N 2 That's ignoring file-rc, unfortunately. Is there an easy way of determining whether a certain init.d script should be started in the current runlevel that works also with file-rc ? Probably we should just make /etc/init.d/foobar restart _not_ start anything if the deamon was not running before. It can be done with little effort there, and works with file-rc. ciao, 2ri -- The light at the end of the tunnel is the headlight of an approaching train. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000, Anton Ivanov wrote: It still does not answer the original question which was about X-only/ non-X runlevel. In other words how to boot in multiuser mode selectively with/without X. Which is quite a sensible question. Example: I had to go into an intermediate single user mode boot on some of my machines after forgetting to turn off xdm after changing video cards. Or during dealing with laptop docking gear. If there was a boot with X disabled and xdm installed it would have made life a bit easier. I must admit I don't really understand the problem here. What prevents you from going back to console mode ? Moreover, even if the X server has a problem and keeps dying, startAttempts in xdm is set to 4 by default. Broken hardware. You assume that X and the hardware behave. On some Neomagic clones X does not always die. It screwes it up so bad that neither text nor graphics are available. Same with some ATIs. Similar situation as described by someone else is when the mode settings will actually smoke your monitor. [snip] -- Anton R. Ivanov ARI2-RIPE mailto:[EMAIL PROTECTED] IP Design Engineer, Global Architecture Level3 Communications The excuse for delaying today's deliverables is: We didn't pay the Internet bill and it's been cut off. /\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian, daemons and runlevels (was: Re: X and runlevels)
On Mon, 04 Sep 2000, Paul Slootman wrote: On Mon 04 Sep 2000, Ethan Benson wrote: It's unfortunate that there's no easy way to find the current runlevel (the usual who -r from Solaris etc. doesn't work), otherwise this piece of code could be used: RL=`who -r` if [ -x /etc/rc$RC.d/S??$PKGNAME ]; then /etc/rc$RC.d/S??$PKGNAME start fi That's ignoring file-rc, unfortunately. Is there an easy way of determining whether a certain init.d script should be started in the current runlevel that works also with file-rc ? I was going to tack this sooner or later (the trust us, we KNOW you want the daemons to start always current state of almost all daemon packages annoys me to no end, and from past flamewars I know I'm not the only one), I think I even warned a few newbies in -user two days ago about this :-) The solution is to *force* all daemon packages to never start a daemon out of its intended runlevel, be it during first install or upgrades (I think this probably requires a policy change). I'd even say this should be a goal for woody, unless we're going to try to get woody out of the door very fast. This would be managed through a simple (for sysvinit. I don't believe it'd be very complex for file-rc either, but I didn't check), standard script/program added to the sysvinit and file-rc packages (and any other future packages of the same sort) which allows a script to query if a certain init.d script should be started [in the current runlevel]. This assumes that the name of a daemon's init.d file is the generic ID for that daemon, but this is the current policy for Debian anyway (it's what you feed to update-rc.d). I should check if the LSB tries to do something like this in a non-braindamaged way, too... just in case. This could (IMHO should, but lets not go there) be expanded later to allow the administrator a bit more control over daemons being started on first install (before he reviewed config files, for example). As long as update-rc.d is called before running this script during package installs and upgrades, it would setup the default runlevels the daemon is supposed to run on. There would be no changes in behaviour of a standard debian install. Any comments? -- 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 pgp2EXPfRW4Wu.pgp Description: PGP signature
Re: X and runlevels
SH == Samuel Hocevar [EMAIL PROTECTED] writes: The reason I ask is because I've been having this exact problem with gpm lately. I like to start it occasionally, because it interfers with my X configuration SHYou might be interested in the `-R' option of gpm then. Yeah, I guess I should have mentioned that I solved that problem (by doing exactly that) last evening. But thanks anyway. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, daemons and runlevels (was: Re: X and runlevels)
On Mon 04 Sep 2000, Henrique M Holschuh wrote: This would be managed through a simple (for sysvinit. I don't believe it'd be very complex for file-rc either, but I didn't check), standard script/program added to the sysvinit and file-rc packages (and any other future packages of the same sort) which allows a script to query if a certain init.d script should be started [in the current runlevel]. This sounds like the most reasonable way of doing it IMHO. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On 04 Sep 2000, Ethan Benson [EMAIL PROTECTED] wrote: also debian believes in leaving the runlevel configuration to the admin to define. [EMAIL PROTECTED] (Gerfried Fuchs) wrote: Sure - but there is the FHS (I hope that I read it there) that defines what at least runlevel 2 and 3 are for. I would really like to see that Debian complies with the FHS in that case, when it complies to it in the other meanings also, quite strict, even. Not quite. The FHS briefly mentions *System V's* runlevel 2 and 3 (along with Berkley's multiuser state). It does not specify anything about runlevels for Linux or any other OS. - Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
On Mon, Sep 04, 2000 at 11:30:06AM +0200, Per Lundberg wrote: EB == Ethan Benson [EMAIL PROTECTED] writes: EB perhaps because in the default configuration there is no EB display manager, and thus no automatic runage of X. Sure. But whenever you install something that gets you a display manager, your system will boot up in X. To get it to boot up in console mode, you have to manually remove the symlinks in your runlevel's script directory. The next time you update the display manager, you'll have to do this again. It is not really convenient. There seems to be a widespread misunderstanding of update-rc.d's behavior on this issue, no matter how many times it is rehashed on this list. Perhaps it needs to be more prominently documented? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
