Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 70689 - Start xdm sooner
Summary: Start xdm sooner
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: Highest normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords: Inclusion
: 138775 150919 155728 (view as bug list)
Depends on: 139284
Blocks: 69579
  Show dependency tree
 
Reported: 2004-11-10 10:57 UTC by Paul Pacheco
Modified: 2007-05-01 05:04 UTC (History)
20 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
fastxdm (xdmfast,2.65 KB, text/plain)
2004-11-10 10:59 UTC, Paul Pacheco
Details
fastxdm (xdmfast,3.31 KB, text/plain)
2004-11-10 12:59 UTC, Paul Pacheco
Details
fastxdm (xdmfast,3.31 KB, text/plain)
2004-11-15 08:00 UTC, Paul Pacheco
Details
Xservers.patch (Xservers.patch,270 bytes, patch)
2004-11-15 08:03 UTC, Paul Pacheco
Details | Diff
copy of Xorg.0.log using fastxdm (xorgfastxdm.log,2.14 KB, application/octet-stream)
2004-11-19 13:32 UTC, Kathy Wills
Details
copy of Xorg.0.log using xdm (xorgxdm.log,25.69 KB, application/octet-stream)
2004-11-19 13:34 UTC, Kathy Wills
Details
Copy of Xorg.0.log using fastxdm (xorgfastxdm.log,2.14 KB, application/octet-stream)
2004-11-19 14:50 UTC, Kathy Wills
Details
Copy of Xorg.0.log using xdm (xorgxdm.log,25.69 KB, application/octet-stream)
2004-11-19 14:52 UTC, Kathy Wills
Details
xdm.patch (xdm.patch,677 bytes, patch)
2004-12-01 10:51 UTC, Paul Pacheco
Details | Diff
xdm.patch (xdm.patch,678 bytes, patch)
2004-12-20 06:34 UTC, Paul Pacheco
Details | Diff
xdm.log (xdm.log,1.82 KB, text/plain)
2004-12-24 15:30 UTC, Donnie Berkholz (RETIRED)
Details
Xorg.0.log (Xorg.0.log,67.78 KB, text/plain)
2004-12-24 15:30 UTC, Donnie Berkholz (RETIRED)
Details
/etc/X11/xdm/Xservers (Xservers,490 bytes, text/plain)
2004-12-24 15:31 UTC, Donnie Berkholz (RETIRED)
Details
messages.log (messages.log,84.97 KB, text/plain)
2005-02-05 00:27 UTC, Donnie Berkholz (RETIRED)
Details
emerge-info.txt (emerge-info.txt,2.04 KB, text/plain)
2005-02-05 00:27 UTC, Donnie Berkholz (RETIRED)
Details
xorg.conf (xorg.conf,4.01 KB, text/plain)
2005-02-05 00:28 UTC, Donnie Berkholz (RETIRED)
Details
starts xdm after lm_sensors and smartd (xdm_monitoring.patch,513 bytes, patch)
2007-02-04 11:37 UTC, Christian Kuenstner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Pacheco 2004-11-10 10:57:08 UTC
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
Comment 1 Paul Pacheco 2004-11-10 10:59:03 UTC
Created attachment 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.
Comment 2 Paul Pacheco 2004-11-10 11:01:12 UTC
This script + bug 69854 save me 40 seconds of boot time (out of 2 minutes)
Comment 3 Paul Pacheco 2004-11-10 12:59:56 UTC
Created attachment 43673 [details]
fastxdm

This one implements stop just like the regular xdm.
Comment 4 Gustavo Sverzut Barbieri 2004-11-11 17:12:23 UTC
It works here, but just to ensure it'll add soon, I add to it:

   before apache2 sshd distccd ntpd
Comment 5 Paul Pacheco 2004-11-12 07:29:00 UTC
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.
Comment 6 Paul Pacheco 2004-11-15 08:00:52 UTC
Created attachment 43995 [details]
fastxdm

Now I tell the x server to start on vt7 rather than the display manager.
Se the patch for that.
Comment 7 Paul Pacheco 2004-11-15 08:03:49 UTC
Created attachment 43996 [details, diff]
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
Comment 8 Kathy Wills 2004-11-18 01:46:04 UTC
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.
Comment 9 Paul Pacheco 2004-11-18 06:33:40 UTC
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
Comment 10 Kathy Wills 2004-11-18 18:35:55 UTC
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. 
Comment 11 Paul Pacheco 2004-11-19 06:39:13 UTC
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?
Comment 12 Kathy Wills 2004-11-19 13:32:55 UTC
Created attachment 44318 [details]
copy of Xorg.0.log using fastxdm

Here is the log when I have tried to boot using fastxdm
Comment 13 Kathy Wills 2004-11-19 13:34:31 UTC
Created attachment 44319 [details]
copy of Xorg.0.log using xdm

Here is a copy of my Xorg.0.log when I have booted using xdm.
Comment 14 Kathy Wills 2004-11-19 13:38:40 UTC
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.
Comment 15 Paul Pacheco 2004-11-19 13:59:16 UTC
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.
Comment 16 Kathy Wills 2004-11-19 14:28:05 UTC
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.
Comment 17 Kathy Wills 2004-11-19 14:50:27 UTC
Created attachment 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.
Comment 18 Kathy Wills 2004-11-19 14:52:05 UTC
Created attachment 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.
Comment 19 Martin Schlemmer (RETIRED) gentoo-dev 2004-12-01 09:50:50 UTC
Problem: what about people that configure more than 6 default getties ?
Statically coding the vt does work, but it is not flexable ...
Comment 20 Paul Pacheco 2004-12-01 10:18:16 UTC
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.
Comment 21 Paul Pacheco 2004-12-01 10:51:18 UTC
Created attachment 45063 [details, diff]
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.
Comment 22 Martin Schlemmer (RETIRED) gentoo-dev 2004-12-01 11:40:17 UTC
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
Comment 23 Martin Schlemmer (RETIRED) gentoo-dev 2004-12-01 11:41:52 UTC
Yes, it OT, but else I forgot again for a year or something.
Comment 24 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-06 00:58:11 UTC
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.
Comment 25 Paul Pacheco 2004-12-06 06:30:06 UTC
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.
Comment 26 Paul Pacheco 2004-12-06 06:32:54 UTC
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.
Comment 27 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-06 10:06:44 UTC
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.
Comment 28 Paul Pacheco 2004-12-06 13:55:08 UTC
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 :)
Comment 29 Paul Pacheco 2004-12-06 14:26:22 UTC
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

Comment 30 Paul Pacheco 2004-12-06 14:44:19 UTC
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.
Comment 31 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-19 13:02:33 UTC
Hey Paul,

Did you test attachment #45063 [details, diff] 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.
Comment 32 Paul Pacheco 2004-12-20 06:29:20 UTC
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.
Comment 33 Paul Pacheco 2004-12-20 06:34:24 UTC
Created attachment 46437 [details, diff]
xdm.patch

fixed the curly brace issue.
Comment 34 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-20 09:43:11 UTC
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.
Comment 35 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-24 15:30:39 UTC
Created attachment 46811 [details]
xdm.log
Comment 36 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-24 15:30:56 UTC
Created attachment 46812 [details]
Xorg.0.log
Comment 37 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-24 15:31:32 UTC
Created attachment 46813 [details]
/etc/X11/xdm/Xservers
Comment 38 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-24 15:31:50 UTC
I'm going on vacation for a week, there's the stuff.
Comment 39 Paul Pacheco 2004-12-27 07:57:35 UTC
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
Comment 40 Paul Pacheco 2004-12-27 08:06:53 UTC
is ssh access out of the question?
Comment 41 Paul Pacheco 2004-12-28 06:34:27 UTC
xorg.conf would also be usefull
Comment 42 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-28 11:06:42 UTC
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.
Comment 43 Paul Pacheco 2005-01-17 06:54:51 UTC
spyderous do you have the info?
Comment 44 Donnie Berkholz (RETIRED) gentoo-dev 2005-01-17 09:39:15 UTC
Yeah I've been sidetracked lately. I'll try to attach it tonight.
Comment 45 Paul Pacheco 2005-01-28 08:15:36 UTC
Spyderous, I have tried, but I can't reproduce the problem. I really need those files or ssh access.
Comment 46 Donnie Berkholz (RETIRED) gentoo-dev 2005-01-28 08:23:00 UTC
Sorry real life getting in the way. I'll try for this weekend or early next week.
Comment 47 Donnie Berkholz (RETIRED) gentoo-dev 2005-01-31 22:30:04 UTC
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.
Comment 48 Donnie Berkholz (RETIRED) gentoo-dev 2005-02-05 00:27:02 UTC
Created attachment 50419 [details]
messages.log
Comment 49 Donnie Berkholz (RETIRED) gentoo-dev 2005-02-05 00:27:19 UTC
Created attachment 50420 [details]
emerge-info.txt
Comment 50 Donnie Berkholz (RETIRED) gentoo-dev 2005-02-05 00:28:03 UTC
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)
Comment 51 Donnie Berkholz (RETIRED) gentoo-dev 2005-02-05 00:28:28 UTC
Created attachment 50421 [details]
xorg.conf
Comment 52 Heinrich Wendel (RETIRED) gentoo-dev 2005-05-16 15:32:30 UTC
any status on this?
Comment 53 Donnie Berkholz (RETIRED) gentoo-dev 2005-05-16 15:35:09 UTC
Last time I tried, it didn't work. I'll give it another shot soon.
Comment 54 Donnie Berkholz (RETIRED) gentoo-dev 2005-06-27 23:37:58 UTC
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
              |            |
Comment 55 Donnie Berkholz (RETIRED) gentoo-dev 2005-06-28 00:07:15 UTC
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.
Comment 56 Roger 2005-06-29 18:53:53 UTC
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.
Comment 57 Joshua Baergen (RETIRED) gentoo-dev 2005-06-29 19:51:38 UTC
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 :)
Comment 58 Gregorio Guidi (RETIRED) gentoo-dev 2005-07-09 12:15:22 UTC
I applied just the patch in attachment 46437 [details, diff] 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. 
 
Comment 59 Joshua Baergen (RETIRED) gentoo-dev 2005-11-13 11:35:47 UTC
Alrighty, just need someone to test this on xdm yet.  I might give it a try on 
entrance at some point as well.
Comment 60 Harm Geerts 2006-01-09 18:04:50 UTC
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  |      |        |        |
     |------|--------|--------|
Comment 61 Donnie Berkholz (RETIRED) gentoo-dev 2006-02-12 23:23:47 UTC
I'm going to add this to modular X soon unless there are any reasons not to.
Comment 62 Donnie Berkholz (RETIRED) gentoo-dev 2006-02-13 12:20:43 UTC
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.
Comment 63 Joshua Baergen (RETIRED) gentoo-dev 2006-02-13 18:38:07 UTC
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.
Comment 64 Donnie Berkholz (RETIRED) gentoo-dev 2006-02-21 21:36:19 UTC
I can't think of any reason not to have this fast xdm be the new default. Can anyone else?
Comment 65 Sebastian Bergmann (RETIRED) gentoo-dev 2006-02-21 21:47:19 UTC
I am using the init.d/xdm script from comment #62 since you posted it and had no problems so far.
Comment 66 Paul Pacheco 2006-02-27 14:05:09 UTC
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
Comment 67 Donnie Berkholz (RETIRED) gentoo-dev 2006-04-19 23:34:45 UTC
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!
Comment 68 LaPaToR 2006-05-08 16:33:28 UTC
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..
Comment 69 Donnie Berkholz (RETIRED) gentoo-dev 2006-05-08 21:29:48 UTC
The whole point of the configuration option in /etc/conf.d/xdm is so that you can disable this functionality.
Comment 70 LaPaToR 2006-05-09 00:36:14 UTC
(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. ;)
Comment 71 Donnie Berkholz (RETIRED) gentoo-dev 2006-07-01 14:54:48 UTC
*** Bug 138775 has been marked as a duplicate of this bug. ***
Comment 72 Donnie Berkholz (RETIRED) gentoo-dev 2006-07-01 17:28:46 UTC
*** Bug 138775 has been marked as a duplicate of this bug. ***
Comment 73 Ioannis Aslanidis (RETIRED) gentoo-dev 2006-08-08 15:07:04 UTC
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.
Comment 74 Jakub Moc (RETIRED) gentoo-dev 2006-08-08 15:12:40 UTC
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.
Comment 75 Donnie Berkholz (RETIRED) gentoo-dev 2006-08-08 16:12:42 UTC
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?
Comment 76 Carsten Lohrke (RETIRED) gentoo-dev 2006-08-08 16:33:25 UTC
(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.
Comment 77 Donnie Berkholz (RETIRED) gentoo-dev 2006-08-09 08:13:23 UTC
(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.
Comment 78 Ioannis Aslanidis (RETIRED) gentoo-dev 2006-08-09 08:22:00 UTC
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.
Comment 79 Jakub Moc (RETIRED) gentoo-dev 2006-08-09 08:24:39 UTC
(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).
Comment 80 Paul Pacheco 2006-08-09 08:43:39 UTC
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.



Comment 81 Donnie Berkholz (RETIRED) gentoo-dev 2006-08-09 08:53:47 UTC
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.
Comment 82 Donnie Berkholz (RETIRED) gentoo-dev 2006-08-09 08:55:35 UTC
(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.
Comment 83 Donnie Berkholz (RETIRED) gentoo-dev 2006-08-09 09:06:07 UTC
(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...
Comment 84 Paul Pacheco 2006-08-09 09:15:01 UTC
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?
Comment 85 Donnie Berkholz (RETIRED) gentoo-dev 2006-08-09 09:36:47 UTC
(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.
Comment 86 Jakub Moc (RETIRED) gentoo-dev 2006-08-14 05:44:58 UTC
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
Comment 87 Ioannis Aslanidis (RETIRED) gentoo-dev 2006-08-14 06:14:26 UTC
(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?
Comment 88 Jakub Moc (RETIRED) gentoo-dev 2006-10-11 14:02:15 UTC
*** Bug 150919 has been marked as a duplicate of this bug. ***
Comment 89 Robert Larkin 2006-10-20 22:52:47 UTC
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.
Comment 90 Robert Larkin 2006-10-20 23:37:33 UTC
(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.
Comment 91 Jakub Moc (RETIRED) gentoo-dev 2006-11-20 00:43:54 UTC
*** Bug 155728 has been marked as a duplicate of this bug. ***
Comment 92 Marcin Deranek 2006-11-22 07:01:35 UTC
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".
Comment 93 Donnie Berkholz (RETIRED) gentoo-dev 2006-11-22 07:08:52 UTC
(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.
Comment 94 Marcin Deranek 2006-11-22 11:45:32 UTC
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 ?
Comment 95 Donnie Berkholz (RETIRED) gentoo-dev 2006-11-22 12:08:25 UTC
(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. =)
Comment 96 Christian Kuenstner 2007-02-04 11:37:02 UTC
Created attachment 109095 [details, diff]
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.
Comment 97 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2007-05-01 05:04:02 UTC
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.