On Sun, May 08, 2011 at 07:53:49PM +0200, Tom Gundersen wrote:

How would you make sure e.g. kdm was started before (or after) another daemon if you use the runlevel approach?

If you use the runlevel approach, DMs start after all DAEMONS. This is usually the right behavior. You start DBUS and other crap and then go for Xorg. -- -- Kwpolska (http://kwpolska.co.cc) stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html GPG KEY: 5EAAEA16 | Arch Linux x86_64, zsh, mutt, vim.

Am Sun, 8 May 2011 19:10:59 +0100 schrieb Magnus Therning <magnus@therning.org>:

[1] As an Arch user for a couple of years this is the first time I've heard using runlevels being suggested.

Isn't this recommended in the Beginner's Guide or somewhere else in the Wiki? Heikol

I don't think so. The word "runlevel" doesn't exist on https://wiki.archlinux.org/index.php/Beginners%27_Guide

It does mention adding display managers to the daemons line.

I have not read all of the documentation on the wiki though, so I'd be grateful to be pointed to something I've missed.

/M

https://wiki.archlinux.org/index.php/Display_Manager includes both methods. Does this really matter? The inittab method isn't going anywhere and I don't see any reason to remove the daemon method unless it becomes a problem for the developers. Arch doesn't come with X pre-installed so there is no "default," only what's recommended in the wiki, which covers both methods as well as many of the issues mentioned in this thread..

Heiko Baums wrote:

https://wiki.archlinux.org/index.php/Start_X_at_boot

Thats the worst wiki page i've ever seen, on any wiki. -- () against html e-mail | usenet & email communication netiquette /\ www.asciiribbon.org | www.netmeister.org/news/learn2quote.html

On 05/08/2011 02:21 PM, Grigorios Bouzakis wrote:

Heiko Baums wrote:

...

https://wiki.archlinux.org/index.php/Start_X_at_boot Thats the worst wiki page i've ever seen, on any wiki.

That wiki page needs a wiki page methinks. -eyes crossed. C

On Sun, May 8, 2011 at 8:05 PM, Kwpolska <kwpolska@gmail.com> wrote:

On Sun, May 08, 2011 at 07:53:49PM +0200, Tom Gundersen wrote:

...

How would you make sure e.g. kdm was started before (or after) another daemon if you use the runlevel approach?

If you use the runlevel approach, DMs start after all DAEMONS.  This is usually the right behavior.  You start DBUS and other crap and then go for Xorg.

This is indeed the safe behavior, and then the two approaches would be equivalent. However, if you use the DAEMONS array you have the flexibility (if you know what you are doing) to optimise it (a lot). Essentially the only thing you need before kdm is dbus (maybe also syslog-ng). I run with DAEMONS=(syslog-ng dbus @kdm ...) If you run a service that relies on the network being up (ssh, netfs, ...), then you need to block on the network daemon, which might take a long time to start. However, it might not be necessary to start kdm after network, so we are loosing a lot of boot time for nothing. As to the problem of a broken system: This is what single user mode is for. No need for a livecd.

From my point of view there is no benefit to the inittab method and some benefit to the daemon method.

Cheers, Tom

On Sun, May 8, 2011 at 9:00 PM, Heiko Baums <lists@baums-on-web.de> wrote:

Am Sun, 8 May 2011 20:29:59 +0200 schrieb Tom Gundersen <teg@jklm.no>:

...

As to the problem of a broken system: This is what single user mode is for. No need for a livecd.

Is this really what single user mode is for? I haven't used it, yet. And how do I switch or boot into single user mode?

Same as booting into runlevel 3, just use 1 (or S) instead. I.e. append "1" to your kernel parameters in grub/syslinux.

...

From my point of view there is no benefit to the inittab method and some benefit to the daemon method.

I see it the other way round, because I still see no benefit from starting daemons in the background. In fact I only saw regressions.

My point was that with using DAEMONS you can do either.

[...] xorg should be started as the last application, if the user doesn't know what he is doing.

Agreed. Cheers, Tom

Am Sun, 8 May 2011 21:08:39 +0300 schrieb jesse jaara <jesse.jaara@gmail.com>:

But if you use runlevel 5 for ?gdm? it will only try to start the xorg 5 times and if it fails it will fall back to console, so that you ?can? fix the problem. :D

Unfortunately there's no automatic fall back to console (runlevel 3), at least not in any case. Heiko

On Fri, May 13, 2011 at 9:50 PM, Tavian Barnes <tavianator@tavianator.com> wrote:

$ tail /etc/rc.conf DAEMONS1=(syslog-ng dbus) DAEMONS2=(named ifplugd net-profiles @alsa @acpid @ddclient @privoxy @openntpd @sshd @mysqld @httpd @git-daemon @samba @sensors @avahi-daemon @cups @crond)

if [ "$RUNLEVEL" = "5" ]; then  DAEMONS=(${DAEMONS1[@]} @kdm ${DAEMONS2[@]}) else  DAEMONS=(${DAEMONS1[@]} ${DAEMONS2[@]}) fi

The best of both worlds.

That's a neat trick! Beware though, that this kind of stuff is absolutely not supported and might break at any moment. Cheers, Tom

On Sat, May 14, 2011 at 12:25 AM, Tavian Barnes <tavianator@tavianator.com> wrote:

Been doing that almost since I've had Arch installed (about 3 years), and no problems so far.  Obviously a person shouldn't do this if they don't understand what it's doing, though.

Is there really any notion of "supported" in Arch anyway?  What support goes away when I do this?

What I meant is that we might change initscripts in the future in such a way that your trick will no longer work. Not saying that we are planning to, just that there is no way for us to test against these kind of custom hacks. If you use this only on your personal system and you are aware of the potential issue, then that's of course fine. Cheers, Tom

On Sun, May 08, 2011 at 08:15:27PM +0200, Heiko Baums wrote:

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

...

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.

Another, arguably easier solution is to pass 'init=/bin/bash' in order to get a terminal to modify DAEMONS. But that's not pertinent to this discussion.

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.

This has actually never happened to me, but I can imagine the irritation. Is there really no way to make the /etc/rd.c-script fail and return the user to a terminal if xorg (or the display manager) fails?

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.

I think the argument of OP was that the inittab method should be the *only* method. If both methods are available, which one should be the default? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

On 05/08/2011 02:15 PM, Heiko Baums wrote:

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.

Not true. You could fix this (rare) situation by booting into single user mode rather than a LiveCD. Not sure I see why the rc scripts should be removed to handle this rare corner case ... DR

Am Mon, 09 May 2011 17:55:06 -0400 schrieb David Rosenstrauch <darose@darose.net>:

Not true. You could fix this (rare) situation by booting into single user mode rather than a LiveCD.

This was already explained by Tom and discussed before. ;-)

Not sure I see why the rc scripts should be removed to handle this rare corner case ...

I never said that the rc scripts should be removed, but the inittab method must also be kept. It was someone else (the OP) who asked for removing them. Or do you mean removing the rc script temporarily from the DAEMONS array if such an issue happens? This can be necessary if xorg fails for any reason and doesn't allow you to switch to the text console. This is not really a corner case. It happened to me not very often, but several times. Heiko

On Sun, May 8, 2011 at 9:26 PM, Grigorios Bouzakis <grbzks@xsmail.com> wrote:

Tom Gundersen wrote:

...

The specific bug you pointed out is not particular to KDM/GDM/slim, but should be fixed for all daemons (proper inheritance of LOCALE), and it is on our TODO list.

Indeed, but i didnt point to this report to prove that the rc.d way doesnt work. Its a 10 month old bug report, which means theres been 9-10 upgrades to KDE. The KDE maintainer didnt fix the problem all this time. Both responces to it have been by Arch developers one of which said the rc.d way sucks and inittab is the proper way and the other who said inittab is the only way and thats what the user should be using. To me that means the rc.d way, even if on most occasions may work, it is unsupported.

If it is unmaintained that is indeed a problem. I have added myself to the bug report you pointed out, and will help with finding a solution (if the people who observe it will answer the questions I put there ;-) ). If there are more kdm rc.d script related bugs, please let me know (I couldn't find any).

Additionally its more error prone, while the inittab method always works, and always works reliably.

This is strange. The kdm rc.d script must be among the simplest in existence, and as far as I can tell it does the same as putting kdm into inittab. I would be interested to see bugs that are confirmed to work with inittab and not with rc.d script (because then I think we might have something weird going on)...

cantabile wrote:

On 05/08/2011 08:19 PM, Grigorios Bouzakis wrote:

...

Hello, can anyone think of a reason the rc.d scripts are added to kdm, gdm and slim? They are not recommended by anyone& they are to be blame for occasional weird problems. The standard and IMO only way is to start them from inittab. They dont come from upstream& i dont know when they were added, i remember them being there ever since i started using Arch, they may come from CRUX or something. I am considering requesting them removal from all display managers. In [0] Pierre said some people want to keep them for backwards compatibility. Backwards compatibility is desired only when something works correctly. Thoughts?

[0]: https://bugs.archlinux.org/task/20109

So, lemme get this straight. You don't like the daemon method, therefore it should be removed? "they are to be blame for occasional weird problems" — not good enough.

Of course, and im the only one who doesnt like it. The developers who said it sucks and that people shouldn't be using it are naturally in favour of keeping them. Thank you for straitening this out! -- () against html e-mail | usenet & email communication netiquette /\ www.asciiribbon.org | www.netmeister.org/news/learn2quote.html

Am Mon, 9 May 2011 20:41:31 +0200 schrieb Rémy Oudompheng <remyoudompheng@gmail.com>:

I never used inittab to launch a display manager and always used rc-scripts, and I will never switch unless I go for systemd. I don't understand the point of removing these scripts, unless you want users to write them themselves. As far as I know, most major distributions that don't use systemd ship rc-scripts for the display managers.

Regarding Gentoo this is not quite correct. At least Gentoo is also using an rc script to start X at boot time but this rc script is started in its own runlevel if I recall correctly. So Gentoo uses a mixture of the inittab/runlevel and the rc script method. But I guess this mixture wouldn't work and is not necessary in Arch Linux. Heiko

Am Tue, 10 May 2011 01:32:19 +0300 schrieb Grigorios Bouzakis <grbzks@xsmail.com>:

If they are unsupported then yes, users who want to use them should be writing them themselves.

Who says that they are unsupported? They are just not recommended as far as I know. And why shouldn't they be installed by the packages? Do they hurt you? You don't need to use them if you don't need them. But why should everybody who wants to use them write his own rc script? Heiko