Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Xdm is the last thing to start. Currently, xdm is started by init, and the /etc/init.d/xdm start just tells init to start it. As stated in /etc/init.d/xdm, it has to start after all the gettys because otherwise xdm will start on vt2 and will conflict with the getty on vt2. This can easily be solved by telling the display manager to start on virtual terminal 7. This way, X can start sooner in the boot process making the machine ready for the user sooner. Reproducible: Always Steps to Reproduce: reboot Actual Results: xdm waits for all init scripts before starting Expected Results: xdm should start as soon as posible
Created an attachment (id=43668) [details] fastxdm This script should be put in /etc/init.d/fastxdm then remove xdm from default run level and add fastxdm This is currently tested only with kdm. I will have to test it and fix it for other display managers.
This script + bug 69854 save me 40 seconds of boot time (out of 2 minutes)
Created an attachment (id=43673) [details] fastxdm This one implements stop just like the regular xdm.
It works here, but just to ensure it'll add soon, I add to it: before apache2 sshd distccd ntpd
If you are using my parallel startup patch, that before does not make xdm start any faster. xdm will start as soon as all it's dependencies finish in both cases. However, that "before" will make apache2, sshd, distccd and ntpd wait for xdm to finish before starting. Normally they would start at the same time.
Created an attachment (id=43995) [details] fastxdm Now I tell the x server to start on vt7 rather than the display manager. Se the patch for that.
Created an attachment (id=43996) [details] Xservers.patch This tells the X server to start on Vt7 so xdm does not conflict with getty. Should work with all display managers. apply with cd / patch -b -p0 < /tmp/Xservers.patch
I tried this on my system. I use kdm. It did not work. It just stopped at the console logon screen. Went back to xdm and x started just fine. I use xorg.
I use kdm and xorg too. Did you apply the patch? did you add fastxdm to the default run level? You can confirm by searching for it in the output of rc-update -s Did you make fastxdm executable (I am not sure if this matters)? chmod a+x /etc/init.d/fastxdm
Yes. I applied the patch and made fastxdm defautlt. As I said, then I rebooted for other reasons, it could not open kdm. First, I tried removing the change the patch made. It still stopped at console and did not go on to kdm. I then made xdm default, rebooted and it went on to kdm without any problem.
Can you check /var/log/Xorg.0.log and see if there is any error, any reason why the X server didn't start? Could you try stopping xdm manually: /etc/init.d/xdm stop and then starting fastxdm manually: /etc/init.d/fastxdm start Does it work? If it gives any error, can you check on the log?
Created an attachment (id=44318) [details] copy of Xorg.0.log using fastxdm Here is the log when I have tried to boot using fastxdm
Created an attachment (id=44319) [details] copy of Xorg.0.log using xdm Here is a copy of my Xorg.0.log when I have booted using xdm.
From KDE when I issue "/etc/init.d/xdm stop" then "/etc/init.d/fastxdm start" it works. I do "rc-update del xdm" then "rc-update add fastxdm default" and restart the computer. I got the above log. It hung at the console. I did "rc-update del fastxdm" then "rc-update add xdm default" and then restarted the computer. I got the above log, and got kdm so I could log into KDE.
From the logs and your comment, it seems the patch is not doing what it is supposed to do. can you check /etc/X11/xdm/Xservers? it should have a line like: :0 local /usr/X11R6/bin/X vt7 If it does not have the vt7, try adding it. I think kdm uses another file: Can you check /usr/kde/3.3/share/config/kdm/Xservers?. Try changing the line that says: :0 local@tty1 /usr/X11R6/bin/X -nolisten tcp to :0 local@tty1 /usr/X11R6/bin/X -nolisten tcp vt7 If it works, let me know and I will adjust the patch accordingly. If it doesn't, post the new Xorg.0.log like before. Thanks for taking the time to help me debug the problem.
As I said before, I had vt7 in /etc/X11/xdm/Xservers but had to remove it. It didn't work and didn't make fastxdm work. It was there the first time I tried fastxdm. I will try it again along with the try to the /usr/kde/3.3/share/config/kdm/Xservers. I'll let you know.
Created an attachment (id=44325) [details] Copy of Xorg.0.log using fastxdm As you will see from this log, the patch changing everything to vt7 has nothing to do with the fact that xdm does not start.
Created an attachment (id=44326) [details] Copy of Xorg.0.log using xdm Here is the log where I had to go back to xdm after fastxdm didn't work.
Problem: what about people that configure more than 6 default getties ? Statically coding the vt does work, but it is not flexable ...
I will make this optional, I will merge xdm/fastxdm and add an option XDYNAMICVT=yes/no to change between them (default to no I guess). Also, I think it is relevant to ask how many people do that. If the percentage is close to 0, it would not be a big deal, they can change kdm/gdm default vt to some other number to allow for more virtual terminals. Note kde 3.3.1 by default has vt 7 set.
Created an attachment (id=45063) [details] xdm.patch Now it is just an option. To enable, open /etc/rc.conf and put XDYNAMICVT="no" somewhere. Don't forget to apply Xservers.patch, and/or change /usr/kde/3.3/share/config/kdm/kdmrc and make sure the line ServerVTs=-7 is uncommented. This is the default with kde-3.3.1, so you may not have to anything.
Also, Spyderous, could we please add this long needed patch: ----- /etc/init.d/xdm should not fail if the DM is already stopped (which is many times (most?) the case if the DM is responsible for the shutdown. --- xdm.orig 2004-12-01 21:38:51.813940584 +0200 +++ xdm 2004-12-01 21:38:58.821875216 +0200 @@ -105,8 +105,6 @@ stop() { --exe ${myexe} &>/dev/null retval=$? - else - retval=1 fi #switch back to original vt
Yes, it OT, but else I forgot again for a year or something.
I don't really think it's appropriate to be switching to X before you can see the status on all of the startup services, especially since they aren't logged at this point in time AFAIK. A way to do this that respects the above would be to start X early but background it until everything else finishes, then switch to X. Another way would be to start logging the boot process, and service status changes in general for that matter. Switching back to the console via ctrl-alt-fn# is an unacceptable solution. In both cases, I leave implementation open to the reader. Check out http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01374.html for some more interesting info on Red Hat's attempts to speed up the boot process. http://www.klika.si/ziga/bootchart/ has a pretty sweet way to graph where the time is wasted, but I see Paul's already found it.
Re to comment #24 Check bug 69579, it includes some charts I made using Ziga's work. You can see, this is one major thing that delays boot. I have done other things to speed up boot: parallel startup bug 69854, avoid runnign modules-update bug 55329. Most of the things they did with red hat don't apply. This is the single best improvement in response time even before those other bugs. Making X start in background does not solve the problem I am trying to solve. Namely: let the user use the computer as soon as posible. The idea is to start X BEFORE most things and let the other things start in background. I agree it is not desirable for everyone, and that is why you have to explicitly set XDYNAMICVT="no" if you want to use it. By default, the behavior is the current one. I am not even suggesting putting that variable by default.
Also, note that even with the current parallel startup, you can not see the status of the services because the [ok] do not show up in the same line as the ebegin message. Therefore you are just waiting for some meaningless text.
Those charts don't seem very helpful to me in discerning exactly what's causing the delays, because you sometimes changed multiple variables between earlier and later ones (e.g., adding both this bug and 55329). There is a ton of stuff on them though, so maybe I'm reading too quickly. Perhaps you could create one that's just adding this onto 69854? I see your idea of wanting to start X soon. But still, I don't think it's appropriate to have no idea what's going on with the services. We can't just assume the parallel startup will stay broken forever. If X starts sooner, wouldn't it make sense to have some sort of display in X of what's going on with the services? Kinda like the bootsplash progress bar. Not sure how that'd work, though.
You can see just in this chart: http://paulpach.no-ip.com/~paul/bootlogs/paul_everything/bootchart.log.svgz that X starts on second 24. Withought this bug, it would start after all the gettys, which mark the end of the chart. that is, it would start at second 42. Granted, there is a bit of overhead caused by X itself, so it might be a bit less than 42. Still roufly the user can log in 15 seconds sooner (on my machine). I will make 2 charts illustrating this if you want. > I see your idea of wanting to start X soon. But still, I don't think it's appropriate to have no idea what's going on with the services. We can't just assume the parallel startup will stay broken forever. You would not enable it until you have everything working. At that point, you are just waiting for useless messages. That is why it should not be the default. Also, I know some devs are working on adding blogd, so all the boot sequence will be logged. At that point, there is no need to see it at boot, you can check it afterwards. > If X starts sooner, wouldn't it make sense to have some sort of display in X of what's going on with the services? Kinda like the bootsplash progress bar. Not sure how that'd work, though. This defeats the purpouse. This does not let the user log in any faster. And also, that project is not fun :)
I don't know much about gdm, but it is my understanding that it is themable. Maybe in the future we could add a little window that displays the messages other processes give in the background. And let you log in in the mean time. Kdm will add themes in 3.4 (me thinks) so it might be possible. That should be a happy medium :). in the mean time can this be merged? :D :D :D
I just though of another argument :) If I have silent bootsplash enabled, I wouldn't care about the messages. So if people enable silent bootsplash, they might want to be able to start X and login manager as soon as posible instead of waiting for the progress bar to finish which is not very informative.
Hey Paul, Did you test attachment #45063 [details] before sticking it up here? + if [ "${XDYNAMICVT" == "no" ] ; then XDYNAMICVT is missing the closing curly brace. Also, over here it didn't switch to vt7 automatically anymore, as it did with the standard init script. I'd guess that's a bug somewhere -- perhaps you could track it down.
Ok, that was embarrasing. :) I'll be glad to track it down. What are you using? kdm? gdm? entrance? xdm? Xorg? Xfree? version? can you post /var/log/Xorg.0.log /var/log/xdm.log /etc/X11/xdm/Xservers if using kdm, /usr/kde/3.3/share/config/kdm/* /usr/kde/3.2/share/config/kdm/* /usr/kde/3.1/share/config/kdm/* backup /usr/kde/3.x/share/config/kdm/* and then try running: genkdmconf --no-old and then try again. Feel free to email me if you don't want to post all that in the bug.
Created an attachment (id=46437) [details] xdm.patch fixed the curly brace issue.
Tried gdm and xdm, using 6.8.0-r4/6.8.1.901. 6.8.1.901 is the more important one, because we'll be moving to 6.8.2 at some point. I'll post the logs tonight, when I have a little time to reproduce.
Created an attachment (id=46811) [details] xdm.log
Created an attachment (id=46812) [details] Xorg.0.log
Created an attachment (id=46813) [details] /etc/X11/xdm/Xservers
I'm going on vacation for a week, there's the stuff.
From your logs, it is clear X is starting in vt 7. So I guess the problem is that the computer is not chvt'ing to vt7 by itself right? Are you using bootsplash? gensplash? version? Are you using genkernel? version? kernel version? baselayout version? emerge info tail -n 1000 /var/log/messages
is ssh access out of the question?
xorg.conf would also be usefull
ssh is out, because the machine's off. I'm using gensplash, not sure of the version -- latest ~x86 as of a week ago or so. Kernel would be gentoo-dev-sources around a similar time frame, ~x86 ... prolly -r9 or -r10. Same situation for baselayout, portage. Not using genkernel. The log is full of PAM garbage, I'll stick some of it up once I get back on Saturday, along w/ the other info. And yeah, clearly not changing VT's is the problem, rather than not starting X. I alluded to that in comment #31.
spyderous do you have the info?
Yeah I've been sidetracked lately. I'll try to attach it tonight.
Spyderous, I have tried, but I can't reproduce the problem. I really need those files or ssh access.
Sorry real life getting in the way. I'll try for this weekend or early next week.
Sorry about the delay, I trashed my box working some bugs out of the 6.8.1.903 migration stuff so you guys don't have to trash yours. =) Should be up and running normally within a few days.
Created an attachment (id=50419) [details] messages.log
Created an attachment (id=50420) [details] emerge-info.txt
supernova ~ # equery list splashutils [ Searching for package 'splashutils' in all categories among: ] * installed packages [I--] [ ] media-gfx/splashutils-0.9.1 (0) supernova ~ # uname -r 2.6.10-gentoo-r6 supernova ~ # equery list baselayout [ Searching for package 'baselayout' in all categories among: ] * installed packages [I--] [ ] sys-apps/baselayout-1.11.8 (0)
Created an attachment (id=50421) [details] xorg.conf
any status on this?
Last time I tried, it didn't work. I'll give it another shot soon.
I retested these patches and they work fine now for me on gdm. But I saw essentially zero speedup, with or without parallel startup. Here's my results: \ RC_PARALLEL | | \ | | \ | | \ | YES | NO \ | | XDYNAMIC \ | | ----------------------------------------- | | YES | 0:58 | 1:07 | | --------------|------------|------------- | | NO | 0:57 | 1:07 | |
After further testing and applying the other boot speedup patches for modules-update and the "more parallel startup," I found that turning XDYNAMICVT on reduced boot time from 0:50 to 0:42. If people can confirm that it works on xdm and kdm, I'll be happy to commit it.
In response to Donnie, I'm guessing your reduction in speed-up time has to deal with how many non-essential services you have starting. It would be great to see these optimizations incorparated into Gentoo tree in order to see X start sooner.
roger: As Donnie said, he'll incorporate the changes once testing is complete on xdm and kdm. If you can help out with either of them, it would be greatly appreciated :)
I applied just the patch in attachment 46437 [details] and set XDYNAMICVT to no, and I confirm that kdm starts without any problem (with or without RC_PARALLEL_STARTUP). As said in comment 54 this does not change the boot time a lot, but it definitely works.
Alrighty, just need someone to test this on xdm yet. I might give it a try on entrance at some point as well.
Tested with kdm and xdm, for xdm I didn't bother to do a non parallel boot. In non-parallel the script is always started last (before local) and this patch doesn't have any influence on it at that point. RC_PARALLEL KDM |-----------------| | YES | NO | X |------|--------|--------| D | | | | Y | YES | 0:51 | 0:57 | N | | | | A |------|--------|--------| M | | | | I | NO | 0:45 | 0:57 | C | | | | |------|--------|--------| RC_PARALLEL XDM |-----------------| | YES | NO | X |------|--------|--------| D | | | | Y | YES | 0:45 | -:-- | N | | | | A |------|--------|--------| M | | | | I | NO | 0:38 | -:-- | C | | | | |------|--------|--------|
I'm going to add this to modular X soon unless there are any reasons not to.
OK, I just tested this out again. Made a slight change, so that xdm really starts as soon as possible and in the boot runlevel instead of default. Here's the depend() in mine: depend() { need localmount # this should start as early as possible # we can't do 'before *' as that breaks it before clock bootmisc consolefont keymaps rmnologin serial urandom # Start X Font Server before X use readahead-list xfs } Works OK -- GDM started at 28 sec, but didn't get a login screen until 40 sec, heard lots of disk thrashing. Wasn't able to get fully logged in until about 90 sec, once my Gnome applets (clock, system monitor, weather, volume) started up.
You should probably add 'acpid' to the 'use' list, since X uses the ACPI daemon if it's started. I'm not sure of the consequences of starting acpid after X, since X might take over the proc interface.
I can't think of any reason not to have this fast xdm be the new default. Can anyone else?
I am using the init.d/xdm script from comment #62 since you posted it and had no problems so far.
I needed to add coldplug to the depends() function as a soft dependency, here is my depend section: # Start X Font Server before X depend() { need localmount # this should start as early as possible # we can't do 'before *' as that breaks it before clock bootmisc consolefont keymaps rmnologin serial urandom # Start X Font Server before X use readahead-list xfs modules hotplug coldplug } I also had to add coldplug to the boot runlevel. This happened because agpgart is loaded by coldplug (if u r using genkernel) so X could not find /dev/agpgart and would not start properly. Other than that, it works great for me using kdm
Finally, this is in xinit-1.0.2-r2 and xdm-1.0.3-r1 using XSTATICVT rather than XDYNAMICVT and enabled by default in /etc/conf.d/xdm. Thanks!
i think that you should create a fastxdm init script so if someone wants to start xdm sooner to add this startup script to his default runlevel and anyone who wants xdm to start as old good days.. to use the default xdm initscript.. I dont like xdm start sooner cause: 1) Dont see the status of other daemon that is very important to me.. 2) Waiting on a blank sceen until KDE to starts 3) Need the same time for KDE to be accesible..
The whole point of the configuration option in /etc/conf.d/xdm is so that you can disable this functionality.
(In reply to comment #69) > The whole point of the configuration option in /etc/conf.d/xdm is so that you > can disable this functionality. > Ok .. Thanks. ;)
*** Bug 138775 has been marked as a duplicate of this bug. ***
Given the fact that having that feature turned on by default causes problems to some users (the ones that have more than 6 ttys), I'd like to ask for that feature to be turned off by default. If we have it turned off by default, it will do no harm to anyone, no side effect. However, leaving it on by default causes people with more than 6 ttys to prevent their keyboards from responding when the login manager (xdm, gdm, kdm, ...) is started. Additionally, the lack of clear documentation on this feature makes things even worse.
Well, w/ XSTATICVT="yes", I can switch to console once, but never can switch back to X until I restart xdm. :/ I'd really prefer to have this disabled by default. Looks like different manifestation of Comment #73.
How many users have more than 6 vt's versus the number who benefit from a faster xdm startup? I will agree that it could be better documented. Care to submit a patch to wherever you think this should happen?
(In reply to comment #75) > How many users have more than 6 vt's versus the number who benefit from a > faster xdm startup? I think this is the wrong question to ask. In most cases it doesn't matter so much, if the system needs 30 seconds or a few minutes to be available. Exceptions as e.g. a multimedia station usually get finetuned anyway. Providing a system that does work out of the box for everyone is far more important.
(In reply to comment #76) > Providing > a system that does work out of the box for everyone is far more important. This system does work out of the box on all Portage-provided configurations, minus bugs, which apparently you hit. Adding extra VT's is nothing anything in Portage does, and supporting every manual change out there is not something I'm interested in.
First of all, you have set a feature on without even documenting it, which has kept some systems broken for months until we realised the problem. Now that we finally find what the problem is, you tell us that our systems will be broken by default, isn't it? Excuse me, but I see no reason why systems have to be broken by default. If you like that feature, document it and allow the users that do want it do enable it themselves. The same way you are asking that this feature is turned on by default, I could ask 10 vts to be set in inittab by default as well, but would that be reasonable? You're doing the same here. Precedent: dhcpcd was removed from system because of a similar reason, thus I find it most reasonable to ask for the same resolution.
(In reply to comment #77) > (In reply to comment #76) > > Providing > > a system that does work out of the box for everyone is far more important. > > This system does work out of the box on all Portage-provided configurations, > minus bugs, which apparently you hit. Erm - Bug 139284, Bug 130916, Bug 121077, plus the one I mentioned, plus the thing now completely ignores any runlevel settings (Bug 138775 marked as dupe of this one) which really doesn't look like a sane behaviour (exactly the same annoyance like w/ the dreaded udev coldplug).
Here is an idea, How about there is a new runlevel just for X (this is similar to what the init scripts do anyway), you can put xdm in the boot runlevel, if you want it to start asap, or you can put X in this new runlevel if you want it to start last, no obscure variable would be required in /etc/conf.d, it is fairly intuitive and very simple to explain in the documentation. Plus the hack that the /etc/init.d/xdm goes through to ensure it starts last would be gone.
Bug 121077 is user error afaict. As for the others, apparently those dm's (kdm and wdm) need some change to always start on vt7 or higher.
(In reply to comment #79) > plus the > thing now completely ignores any runlevel settings (Bug 138775 marked as dupe > of this one) which really doesn't look like a sane behaviour (exactly the same > annoyance like w/ the dreaded udev coldplug). Uh. no. That is not what the bug says, and if the bug does imply that, it's wrong. It simply starts earlier in the _same_ runlevel, because it no longer sits around waiting for the runlevel to finish.
(In reply to comment #80) > How about there is a new runlevel just for X (this is similar to what the init > scripts do anyway), you can put xdm in the boot runlevel, if you want it to > start asap, or you can put X in this new runlevel if you want it to start last, > no obscure variable would be required in /etc/conf.d, it is fairly intuitive > and very simple to explain in the documentation. Plus the hack that the > /etc/init.d/xdm goes through to ensure it starts last would be gone. That is an interesting idea. I don't know how to get baselayout to run an additional level after 'default' rather than instead of 'default' with the softlevel kernel parameter...
what if I made a patch, would that be something to consider or would that need to be taken to the baselayout guys? Do you see something wrong with that approach? I guess my question is: would I waste my time if I worked on doing that?
(In reply to comment #84) > what if I made a patch, would that be something to consider or would that need > to be taken to the baselayout guys? Do you see something wrong with that > approach? Would need to pass by baselayout people. But first it's worth examining whether it's already possible ... > I guess my question is: would I waste my time if I worked on doing that? It's always a possibility. But I can see how the ability to add additional runlevels rather than substitute one for default could be useful in a more generic sense.
You can create your own runlevel just fine by adding a directory to /etc/runlevels. # mkdir /etc/runlevels/X # rc-update add xdm X * gpm added to runlevel X
(In reply to comment #86) > You can create your own runlevel just fine by adding a directory to > /etc/runlevels. > # mkdir /etc/runlevels/X > # rc-update add xdm X > * gpm added to runlevel X And when does this runlevel actually 'run'? Do we have to add it to inittab?
*** Bug 150919 has been marked as a duplicate of this bug. ***
After an update I found that I could not switch VT's anymore, and I have to manually mount my movies directory that used get mounted with everything else. The forums led me to this bug. Changing the STATICVT to "no" fixed both of these problems. I can see that this would be seen as a neato feature for many users, but not ALL, so it clearly shouldn't be on by default. Stable and works out of the box as expected for everyone should ALWAYS be the default. Faster and cool/shiny should be the option that requires extra action in all cases.
(In reply to comment #89) > After an update I found that I could not switch VT's anymore, and I have to > manually mount my movies directory that used get mounted with everything else. > The forums led me to this bug. Changing the STATICVT to "no" fixed both of > these problems. > > I can see that this would be seen as a neato feature for many users, but not > ALL, so it clearly shouldn't be on by default. Stable and works out of the box > as expected for everyone should ALWAYS be the default. Faster and cool/shiny > should be the option that requires extra action in all cases. > Correction, I still cannot switch VT's...still trying to find what else changed.
*** Bug 155728 has been marked as a duplicate of this bug. ***
Would it be possible to start consolefont before xdm starts ? When xdm is started first, consolefont corrupts X server display. This situation only happens when STATICVT is set to "yes".
(In reply to comment #92) > Would it be possible to start consolefont before xdm starts ? > When xdm is started first, consolefont corrupts X server display. This > situation only happens when STATICVT is set to "yes". Done, remerge xinit to get the fix.
I see the comment: # (#70689 comment #92) Start after consolefont to avoid display corruption but I miss 'consolefont' on 'after' list.. or am I missing something ?
(In reply to comment #94) > I see the comment: > > # (#70689 comment #92) Start after consolefont to avoid display corruption > > but I miss 'consolefont' on 'after' list.. or am I missing something ? Check again in an hour. =)
Created an attachment (id=109095) [details] starts xdm after lm_sensors and smartd xdm should be started after lm_sensors and smartd (and possibly other hardware monitoring deamons/scripts) because gkrellm (and others?) depend on those subsystems and breaks if you log in too fast.
Alright, I've talked with dberkholz and we're closing this bug. People, please let this bug die. If anyone has any more requests for services to be started before or after xdm, open a new bug about that. Thanks.
