Can "startup applications" be less cumbersome?

Question

With this tip I saw there is a total of about 60 applications being launched by startup applications, and at the moment I have to sit back and wait about 45s while the desktop is unresponsive...

How does startup applications work? can I tweak it in some way to make these apps start more gradually, not all together?

I don't want to disable any of them, just stop them all being loaded simultaneously and freezing the desktop

Answer 1

First I saw this tip, but sleep 20;xscreensaver -nosplash seems not to work anymore on Ubuntu 14.04.

So I coded this script execLater.sh and put it at a place in my $PATH, chowned it root:root and mode permissions rwxr-xr-x, and put it on a fully root:root folder structure like /usr/local/bin.

sleep $1;shift;"$@"

So it sleeps before executing the command.

Show all hidden startup applications by following this tip

Now for each startup application.

If there is, for example, this:

xscreensaver -nosplash

change to this below, where "20" is the delay; I used up to "60" knowing I dont care much for some applications; and a minimum of "5" for the ones I care most.

execLater.sh 20 xscreensaver -nosplash

The tricky part

each of these below must have an exclusive delay of "1" because everything else depends on them

/usr/bin/gnome-keyring-daemon --start --components=secrets
/usr/bin/gnome-keyring-daemon --start --components=pkcs11
/usr/bin/gnome-keyring-daemon --start --components=gpg
/usr/bin/gnome-keyring-daemon --start --components=ssh
/usr/lib/unity-settings-daemon/unity-fallback-mount-helper
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
gsettings-data-convert
start-pulseaudio-x11
nautilus -n

My guess is, when all 60 apps startup at same time, these above take longer to complete and so the whole desktop stays unavailable...

If you log when each command was executed, you will understand what applications must have delay of "1", because all others are "actually only executed (?)" or "called?" after these; the above list is not fixed, it is just a tip, just logoff and login (no need to reboot to complete this list) so you can make the tests until you are satisfied with the results - now my desktop is available after only 5 seconds :)

Answer 2

@Aquarius Power's suggestion is helpful, but there are easier ways to control the running of things in the background in a startup script. This first assumes you have a startup script of some sort - if not, it might be useful to create a startup script, make it executable, and then add it to your startup items. You could then remove things from the list of startup items and start them up in your script with some delay - but you have to make sure they handle any ordering dependencies.

And you could use the 'execLater' script idea that Aquarius has, but an easier way to run things in the background that allows for some amount of ordering is to use the shell's ability to start a full shell line in the background.

For example, this in a shell script:

sleep 20 ; run_something
run_something_else

Will cause the shell script to block on that line for 20 seconds before running anything after it such as 'run_something_else'

This doesn't work because it only puts the 'sleep' command in the background and then runs 'run_something' immediately:

sleep 20 & ; run_something

The solution? Spawning a new shell and putting that in the background:

( sleep 20 ; run_something ) &

That will combine the "sleep 20" and the "run_something" and put them both in the background.

This can be combined into more complicated dependencies. For example, I have a process that starts up my music daemon (mpd) and I don't want to start my two clients (sonata and cantata) until the music player is up - and I run wmctrl to make cantata sticky to all desktops. And I don't want any of this to block the rest of my startup script, so I have:

( sudo /root/startMPD ; sleep 3 ; sonata & cantata & sleep 5 ; wmctrl -r cantata -b add,sticky ) &

Although I actually use full paths for everything. Note that sonata and cantata start up in the background and then the sleep 5 holds the wmctrl to give cantata a chance to startup. It helps to understand that in a shell, these two lines are the same:

cantata & ; sleep 5

cantata & sleep 5

It's also worth knowing that you can make future commands dependent on whether previous commands were successful using '&&' and '||' (note the difference between '&&' and '&'. For example if you ran your shell script on many systems and only some had cantata installed you could do:

cantanta && ( sleep 5 ; wmctrl ... )

Notice we needed the parens again, otherwise only the 'sleep 5' would be conditional and the wmctrl would not be. You can test this yourself in a shell with simple examples, such as:

ls /does_not_exist && ( echo a ; echo b )

If it gets too complicated, then you might want to consider changing to a more sophisticated scripting language such perl/ruby/python/etc..