[SOLVED, kind of] Slow cold start of DE/WM

caminoix · 2011-06-21 07:37:16

Hello,

for some ten days now, I've been experiencing a very slow cold start of de/wm's. My usual wm is XMonad; at first I thought that it was the problem: here.

I haven't changed anything in my config around the time when it started. The only thing that I can think of that I did was installing Gnome. I only ran it as a new user created specifically for that purpose. The lag occurs both with this account and with my usual account. I also tried installing XFCE and running it as another user – the same, and running scrotwm from my usual account – still the same.

I start de/wm's via ~/.xinitrc. Before the de/wm launch command, I have a couple of settings and programs (feh, dzen, amixer &c.). They all start rather fast (I made .xinitrc log the times, and besides I can see the background image appear and dzen start, then there's a long pause, and XMonad starts).

The lag only occurs during cold start. After restarting the wm/de, the X, logging out and in or as another user, everything starts pretty fast, like it used to up until around ten days ago. It is independent of whether daemons are backgrounded in /etc/rc.conf or not (syslog-ng cpufreq dbus @net-auto-wireless @laptop-mode @crond @alsa @sensors).

Can you please help me?

Last edited by caminoix (2011-06-25 06:38:10)

Inxsible · 2011-06-21 14:28:27

Have you changed over to the new rc.conf? Are you blacklisting any modules?

is this an eeepc and you are using eeepc_laptop modules? If so have a look at this thread: https://bbs.archlinux.org/viewtopic.php?id=120995

caminoix · 2011-06-21 16:29:54

I will admit my rc.conf was slightly outdated. I've changed over to the new one but unfortunately this didn't solve my problem.

Yes, I am blacklisting a few modules (see below).

It's not an Eee PC. It's a Dell Studio 1737, and so I am not using any eeepc_laptop modules.

My rc.conf (comments stripped; otherwise full):

LOCALE="en_US.UTF-8"
DAEMON_LOCALE="no"
HARDWARECLOCK="UTC"
TIMEZONE="Europe/Warsaw"
KEYMAP="us"
CONSOLEFONT="lat1-16.psfu.gz"
CONSOLEMAP="8859-2"
USECOLOR="yes"
VERBOSE="3"

MODULES=(acpi-cpufreq cpufreq_ondemand cpufreq_powersave tg3 iwl3945 !pcspkr snd-via82xx !snd_pcm_oss !snd_mixer_oss !snd_seq_oss intel_agp)

UDEV_TIMEOUT=30

USEDMRAID="no"

USEBTRFS="no"

USELVM="no"

HOSTNAME="kamil-studio-arch64"

WIRELESS_INTERFACE="wlan0"

NETWORK_PERSIST="no"

DAEMONS=(hwclock syslog-ng cpufreq dbus @net-auto-wireless @laptop-mode @crond @alsa @sensors)

Inxsible · 2011-06-21 16:31:57

You should read the announcements and also pay attention to the pacman output. There have been changes to how we blacklist modules.

http://www.archlinux.org/news/changes-t … cklisting/

Implement those and see if the delay persists or not.

EDIT: The rc.conf that you have listed here is still the old version. You haven't updated it completely. The WIRELESS_INTERFACE is no longer supported in addition to the changes in blacklisting.

listdata · 2011-06-21 16:59:16

If you don't know already, you can use

yaourt-C

to clean up all obsolete/changed configuration files (rc.conf, mkinitcpio.conf, etc.). I always run this command after a big upgrade to keep all system files in line.

caminoix · 2011-06-21 19:45:26

@Inxsible:
You are right, I should read the announcements. I'm sorry. I implemented the blacklisting changes but unfortunately this wasn't it.
WIRELESS_INTERFACE in rc.conf is required by netcfg. I changed my manager to wicd. I could then delete the line but this still wasn't it.

@listdata:
I didn't know about it, thanks for the tip! But will it simply delete my obsolete config files? Will I have to set everything up anew? I can't find any clarification on the exact behaviour.

----------------

I did some tweaking to my .xinitrc: as listdata's "echo "$(date)"" trick (here) gave no enlightening results, I tried to combine it with the workaround from the wiki on .xinitrc – which made me no smarter, either. I returned to the previous, simpler version (just "exec ck-launch-session xmonad") but I also appended "&"'s to all the lines in my .xinitrc. I thought it wouldn't change a thing because previous tests with logging showed they all start pretty fast. Surprisingly (to me, at least), I can see an improvement.

Now feh, dzen, … and XMonad all start almost simultaneously and instantly, right after the start of X. However, the login screen (with boot messages) stays for considerably longer and it takes longer for any program to start if I launch it as soon as XMonad appears. The overall time is now shorter than it was an hour ago but still longer than it was two weeks ago and before that. It's something I can live with now but I'd surely appreciate a tip or two.

listdata · 2011-06-21 21:12:22

caminoix wrote:

@listdata:
I didn't know about it, thanks for the tip! But will it simply delete my obsolete config files? Will I have to set everything up anew? I can't find any clarification on the exact behaviour.

Hmm, both the manpage and the Wiki say very little about this. So here's the rundown: when you run "yaourt -C", it will launch a nice, interactive, menu-driven cleanup session. It does help to know how to use your text editor of choice. For me, I have my EDITOR set to /usr/bin/vim, and yaourt does vimdiff (splitscreen of old config and new config, with highlighted differences) on the new vs. old config file and lets you clean up the files as necessary (usually to bring up the old config up to date while taking cues from the new config's syntax). "Suppress" means to delete the .pacnew file, while "Replace" means to replace the old config with the contents of the .pacnew file. If you don't like doing this in a menu-driven way, you can just take note of the conflicting files that yaourt catches, and then manually clean up those files on your own.

caminoix wrote:

I did some tweaking to my .xinitrc: as listdata's "echo "$(date)"" trick (here) gave no enlightening results, I tried to combine it with the workaround from the wiki on .xinitrc – which made me no smarter, either. I returned to the previous, simpler version (just "exec ck-launch-session xmonad") but I also appended "&"'s to all the lines in my .xinitrc. I thought it wouldn't change a thing because previous tests with logging showed they all start pretty fast. Surprisingly (to me, at least), I can see an improvement.

Yes, it's always good to background those processes just in case. From what I understand appending "&" causes the shell to background it immediately, and this method should be used even for commands that background themselves, as this avoids waiting for the command to set itself up (who knows, maybe it reads a ton of config files before doing anything else) before backgrounding itself.

caminoix wrote:

Now feh, dzen, … and XMonad all start almost simultaneously and instantly, right after the start of X. However, the login screen (with boot messages) stays for considerably longer and it takes longer for any program to start if I launch it as soon as XMonad appears. The overall time is now shorter than it was an hour ago but still longer than it was two weeks ago and before that. It's something I can live with now but I'd surely appreciate a tip or two.

I understand your frustration, but there are so many variables here --- the most problematic one is not knowing which newly installed packages slowed down the system. Another problem is not knowing which configuration file is worsening the situation (although, "yaourt -C" may correct this). The easiest way out is to just do a fresh install, of course...

Inxsible · 2011-06-21 23:19:47

if you want a gui to compare the difference between the conf files and the pacnew files, meld is a great program. I use meld to merge pacnew files everytime there is an update which creates a pacnew file.

caminoix · 2011-06-22 16:52:25

@listdata:
"Yaourt -C": that's great. I was a little afraid at first but now I gave it a try and it looks great. Thank you!
Backgrounding: just of curiosty, am I supposed to background XMonad, too? If not, could you please explain why?
Frustration: nah, that's too strong a word. (Hm, unless my stylistics in English are mistaken.) It's definitely not worth the time of setting up a fresh install. I just don't like it when my computer misbehaves

@Inxsible:
Thanks for the tip. I'm trying to cut down the number of programs I use so I usually do such comparisons with Vim but meld looks really nice and I'll give it a try.

----------------

Impossible as it looks, it seems to me that my boot times have now gotten irregular. I'll need to test a little longer. I made a bootchart. I don't really know how to read it but I can see XMonad takes very little time and indeed this was my impression on this boot. Overall, 27 seconds is not bad. My lucky number, actually I can't help the feeling that the $wmpid trick from here really speeds up things. Is it possible?

Last edited by caminoix (2011-06-22 17:03:39)

listdata · 2011-06-23 00:28:57

caminoix wrote:

@listdata:
"Yaourt -C": that's great. I was a little afraid at first but now I gave it a try and it looks great. Thank you!
Backgrounding: just of curiosty, am I supposed to background XMonad, too? If not, could you please explain why?

Backgrounding xmonad: this doesn't make sense. Backgrounding's sole purpose is to launch the command as a separate process, so that the shell can execute the rest of the script as fast as it can. That is,

cmd1 &
cmd2

means "since cmd2 doesn't depend on cmd1 finishing before it, launch cmd1 in the background (as a separate process) and then launch cmd2 right away." In your case, if you background xmonad as well, it would be conceptually like this:

cmd1 &
cmd2 &

and there would be no speed difference, since nothing comes after cmd2 (xmonad). Experiment if you must.

caminoix wrote:

Frustration: nah, that's too strong a word. (Hm, unless my stylistics in English are mistaken.) It's definitely not worth the time of setting up a fresh install. I just don't like it when my computer misbehaves

Judging by the time and effort you spent over this mystery problem, your "stylistics" in English are mistaken.

caminoix wrote:

Impossible as it looks, it seems to me that my boot times have now gotten irregular. I'll need to test a little longer. I made a bootchart. I don't really know how to read it but I can see XMonad takes very little time and indeed this was my impression on this boot. Overall, 27 seconds is not bad. My lucky number, actually I can't help the feeling that the $wmpid trick from here really speeds up things. Is it possible?

The 27 seconds is based on the bootchart, which only times all the console messages/boot stuff before xmonad really begins (you can see this yourself as xmonad is at the very end). So you're using the wrong measurement... Going back to your first post:

caminoix wrote:

I start de/wm's via ~/.xinitrc. Before the de/wm launch command, I have a couple of settings and programs (feh, dzen, amixer &c.). They all start rather fast (I made .xinitrc log the times, and besides I can see the background image appear and dzen start, then there's a long pause, and XMonad starts).

You are talking about this "long pause", right? By the time the background image has appeared, we are already outside of bootchart's range. Thinking on this quote again, I'm curious: what exactly do you mean by xmonad "starting"?

As for the $wmpid trick, I don't like that approach. It will probably work without errors in practice, but technically it is wrong. Supposedly, the point of that trick is to make your WM start before the other stuff in the .xinitrc script:

#!/bin/bash

openbox & wmpid=$!

urxvtd -q -f -o &
xscreensaver -no-splash &
fbpanel &

wait $wmpid

But it's putting openbox in the background! As I understand it, there is no guarantee that the openbox command will have really started before the rest of the commands (urxvtd, xscreensaver, fbpanel) start. From what I can tell, the person who wrote the above wanted fbpanel to start after openbox. The correct (and sane) way would be to start fbpanel from a script that is launched by openbox (surely there are hooks for this; xmonad's equivalent is the startupHook stuff in xmonad.hs).

Fetid Frog · 2011-06-24 23:06:22

caminoix wrote:

The only thing that I can think of that I did was installing Gnome.

I updated my Dad's laptop about a week ago and found that Gnome took ages to start, and there was heavy disk usage for a few minutes after. I thought it must be because of Gnome 3, so I installed KDE and had the same problem, until I uninstalled Gnome. Gnome wasn't running, but some part of it (or a dependency) must have started automatically.

Have you tried uninstalling Gnome to see if that was the problem?

Fetid Frog · 2011-06-24 23:29:15

Fetid Frog wrote:

Have you tried uninstalling Gnome to see if that was the problem?

I am assuming that the problem occurs for a cold start into Gnome as well. If it doesn't then my previous answer probably won't help you.

caminoix · 2011-06-25 06:35:29

@listdata:
Thanks for the explanation on backgrounding and why the $wmpid trick is wrong. I moved stopping bootchart to XMonad's startupHook. I can see no real difference between the charts stopped by .xinitrc and those stopped by XMonad. There probably must be some but it's tiny. I guess it would be more obvious with KDE or something else big.
I now installed preload. We'll see how much that helps. My boot times have gotten rather inconsistent, ranging from 0:27 to 0:45 but I want to believe it's preload learning.

@Fetid Frog:
Well, I didn't really want to blame Gnome for my problem. Firstly because I like it and secondly because I always ran it from another user's account. In fact, I installed quite a few de's (I was going to show Linux to a friend) and the lag happened with each one of them, but only at cold start. Now I removed all, leaving only the dependencies for programs that I actually normally use, very few of them, but there is no noticable difference.

----------------

I made a lot of changes since the lag began. I always kept notes what I did and what the results were. The last couple of boots went smoothly and quickly. But to tell the truth, I can hardly see any correlation between my actions and boot times. Backgrounding everything in .xinitrc seems to have helped – which, btw, I fail to understand as those commands which were not backgrounded before didn't take long at all to run (such as defining a variable). It seems that preload is helping, too. Other than these two, all my actions appear to have been in vain. So, my lag apparently has been worked around rather than fixed, as my boot times are now pretty much the same as they were a fortnight ago when neither of these two fixes was in action.

I'll leave it where it is. I'm quite happy with how it works now and don't want to spend more time playing around.

----------------

Thank you very much for your help and time! I appreciate all your efforts and your time spent on helping me. Arch has a wonderful community!

smartass · 2011-06-25 07:11:48

If you are desperate and use pure ext4 partitions, you could try e4rat, it's in the AUR.
Beware, it's still experimental. But it's amazing

caminoix · 2011-06-25 07:31:42

smartass wrote:

Beware, it's still experimental. But it's amazing

Wow, this does look amazing. I'll have to consider whether I care more for all my work or for optimizing my system. Hm, that's a tough one. (Unfortunately, no irony in there.)

smartass · 2011-06-25 10:36:48

Check out the e4rat topic thread, the only major problems experienced by the arch community so far have been these:
1) somebody had all his data erased, because his ext4 was converted from ext3 without applying extents
2) there was an issue with udev 167, synaptics wouldn't load properly, the next release of udev fixed it.
3) some people reported problems with file/dir names containing spaces

Another thing you may want to look into is systemd, probably more stable than e4rat and used by quite a few archers (also check its thread and wiki)

Last edited by smartass (2011-06-25 10:39:14)

caminoix · 2011-06-26 21:42:25

Haha, point 1. looks pretty harmless I must give it all a good thought. Thank you for the advice!

Arch Linux

#1 2011-06-21 07:37:16

[SOLVED, kind of] Slow cold start of DE/WM

#2 2011-06-21 14:28:27

Re: [SOLVED, kind of] Slow cold start of DE/WM

#3 2011-06-21 16:29:54

Re: [SOLVED, kind of] Slow cold start of DE/WM

#4 2011-06-21 16:31:57

Re: [SOLVED, kind of] Slow cold start of DE/WM

#5 2011-06-21 16:59:16

Re: [SOLVED, kind of] Slow cold start of DE/WM

#6 2011-06-21 19:45:26

Re: [SOLVED, kind of] Slow cold start of DE/WM

#7 2011-06-21 21:12:22

Re: [SOLVED, kind of] Slow cold start of DE/WM

#8 2011-06-21 23:19:47

Re: [SOLVED, kind of] Slow cold start of DE/WM

#9 2011-06-22 16:52:25

Re: [SOLVED, kind of] Slow cold start of DE/WM

#10 2011-06-23 00:28:57

Re: [SOLVED, kind of] Slow cold start of DE/WM

#11 2011-06-24 23:06:22

Re: [SOLVED, kind of] Slow cold start of DE/WM

#12 2011-06-24 23:29:15

Re: [SOLVED, kind of] Slow cold start of DE/WM

#13 2011-06-25 06:35:29

Re: [SOLVED, kind of] Slow cold start of DE/WM

#14 2011-06-25 07:11:48

Re: [SOLVED, kind of] Slow cold start of DE/WM

#15 2011-06-25 07:31:42

Re: [SOLVED, kind of] Slow cold start of DE/WM

#16 2011-06-25 10:36:48

Re: [SOLVED, kind of] Slow cold start of DE/WM

#17 2011-06-26 21:42:25

Re: [SOLVED, kind of] Slow cold start of DE/WM

Board footer