Re: Display Manager rc.d scripts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Am Sun, 8 May 2011 19:53:49 +0200
schrieb Tom Gundersen <teg@xxxxxxx>:

> While I don't have a firm opinion about this, I tend to disagree with
> you. I have always been using the rc.d scripts and find they work
> fine.
> 
> We don't really implement runlevels in Arch, so the half-way approach
> of using the runlevels to control only one daemon seems strange to me.
> Why is kdm/gdm/slim different from all the othe daemons we have. How
> would you make sure e.g. kdm was started before (or after) another
> daemon if you use the runlevel approach?

kdm etc. should only be started as the last rc script as far as I know,
at least it doesn't make much sense to start it before other scripts.
The same is done with the inittab method.

The reason why I prefer and need the inittab method is if there are
issues with xorg which prevents from switching to a text console which
already happened in the past.

With the rc scripts it's only possible to having started xorg at boot
time if the script is in the DAEMONS array. So if xorg fails for a
reason and doesn't allow you to switch to console you need a LiveCD to
first remove it from the DAEMONS to be able to use the system again.

With the inittab method you can easily add two entries to the
bootloader's config. One which boots into runlevel 3 and one which
boots into runlevel 5. So if xorg makes problems you still can easily
boot into the text console and fix the problem.

And it doesn't make any difference if you start or stop xorg at
runtime by running `/etc/rc.d/kdm stop` resp. `/etc/rc.d/kdm start` or
`telinit 3` resp. `telinit 5`.

So the inittab method must be kept while I don't have an opinion
whether the rc scripts shall be kept or not.

Heiko


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux