Thursday, 16 June 2011

UnderStanding KDE Launch Sequence

Its time to begin some serious work, I am already behind schedule, I will have to choose an area to work-on and then move-on to doing some instrumentation/benchmarking to see where the most time is spent, and where the efforts have to be focussed. I have decide to take a look at complete launch sequence right from KDM to the Plasma Shell, with Akonadi Application. My modest assumption, at this stage is that the bulk of the time for all the applications is spent on the transfer from one process to another, from startkde/kdeinit/kded etc. and their tie-up together, maybe we could unify this a bit more. Maybe also add some timing instrumentation/debug output, to see where time is spent.

Having a more detailed look on the entire start-up sequence :-

KDE Display Manager 
   startkde script (executes 2 main functions) ----> 
(1). kdeinit (starts various services)
   dcopserver + klauncher + kded + kcminit
(2). ksmserver

Process 1:-
The user gets authenticated at start-up by entering the user-name and password at KDE Display Manager (KDM). KDM then executes startkde script, this scripts performs two vital functions, and calls the following scripts :-

LD_BIND_NOW=true kdeinit +kcminit +knotify
Starts the kdeinit master process, which in-turn starts all other KDE processes. The arguments behind kdeinit are the names of additional services to be started. The + indicates that kdeinit needs to wait till the service has finished.
                ## Haven't clearly understood the script ##

kwrapper ksmserver $KDEWM 

Starts the kde's session manager. On startup the session manager starts auto-start applications and it restores applications from the previous session. The session manager determines the lifetime of the session. When this process exits, the user is logged out.

Process 2:-
kdeinit master process begins after the startkde script gets executed. kdeinit can start normal binary program files as well as kdeinit loadable modules (KLMs). KLMs work just like binary program files but can be started more efficiently.

for example :-
> ps aux
waba     23184  0.2  2.1 23428 11124 ?       S    21:41   0:00 kdeinit: Running...
waba     23187  0.1  2.1 23200 11124 ?       S    21:41   0:00 kdeinit: dcopserver --nosid
waba     23189  0.2  2.4 25136 12496 ?       S    21:41   0:00 kdeinit: klauncher
waba     23192  0.7  2.8 25596 14772 ?       S    21:41   0:00 kdeinit: kded
waba     23203  0.8  3.4 31516 17892 ?       S    21:41   0:00 kdeinit: knotify

kdeinit in the first line: Running... indicates the master kdeinit process. The other processes listed are programs started as KLMs.

Process 3:-
BackGround/Subprocesses :-

1. dcopserver 
# confusion? - is it any different from the dbus daemon that starts on system booting ??? #
 The doci says "dcopserver is a deamon which provides inter-process communication (DCOP) facilities to all KDE applications." Which is pretty similar to dbus-daemon, which provides inter-process communication (IPC) facilities to all KDE applications as well as several other system components, such as HAL, network manager, power manager and various non-KDE desktop applications.

2. klauncher
klauncher is a deamon which is responsible for service activation within KDE. It operates in close connection with the kdeinit master process to start new processes. KDE applications communicate with klauncher over dcop in order to start new applications or services.

3. kded
kded is a generic KDE daemon. It has the ability to load various service modules and run these in the background. The Service Manager in the Control Center can be used to monitor the status of the service modules and to disable certain services.

4. kcminit
kcminit executes initialisation services during startup. Initialisation services are specified in the .desktop files of applications or services via the X-KDE-Init line. Initialisation services are typically used for initialisating hardware based on user specified settings. kcminit --list can be used to show all initialisation services and kcminit can be used to execute a single service explicity. This can be useful when investigating start-up problems.
## More Understanding required ##

Process 4:-
ksmserver is KDE's session manager. On startup the session manager starts auto-start applications and it restores applications from the previous session.

Whether to auto-start an application can be conditional upon some configuration entry determined by the X-KDE-autostart-condition entry in the .desktop file. The KDE session manager also restores one of the previous sessions. A session contains of a collection of applications as well as application-specific information that reflects the state of the applications at the time the session was saved. Sessions are stored in the ksmserverrc configuration file and contains references to application-specific state information. The application specific state infomation is saved in $KDEHOME/share/config/session.

For example, if ksmserverrc contains:


Then the application specific state information for kwin and konsole can be found in





The state information of kwin contains the location of the application windows of all the other applications in the session.

At this point the order of execution with respect to ksmserver is not very well understood by me, like what happens immediately after the startkde script, if the ksmserver script gets executed alongside, kdeinit, then the values returned by ksmserver would have to communicate in some-way with the klauncher and kded.
Technorati Tags: , , , ,


  1. Credits :- Mentor :- Martin T. SandsMark

  2. DCOPServer is simply for KDE3. It's deprecated and replaced by dbus. Not sure why your system shows that probably have kde3 apps installed somewhere.

  3. Hello sreich,
    Thanks for clearing my doubt, I couldn't find the dcopserver deamon my-self in my user and system processes, but I came across it, reading the start-up sequence documentation. Thank You for pointing out that the different daemons for KDE3 and KDE4 respectively.

  4. This post is an improvised form of the original post by lennart poettering, the creator of systemd. Forgot mention the source ... urghhh...

    Original text can be read at