20

I'm looking for a good overview documentation describing the the stack of daemons and services involved in a modern Linux session. Although having read various documentation about dbus, and systemd, I still don't get the big picture.

In particular, I'm looking for answers to these questions (don't answer the questions, they should only clarify what kind of documentation I'm looking for):

  • After logging in, which process is the root of the user's session?

  • Which processes should be started, and why? I'm looking for a Desktop-agnostic answer, no matter whether Gnome, KDE, FVWM, or a simple shell is started.

  • What role do all these daemons play? Which of them would run alone, which depend on others? Which one should be started by whom, why, and for how long? And who should maintain that zoo?

I'm asking, because I found that I have a whole zoo of daemons running right after booting: systemd-journald, systemd-udevd, dbus-daemon, systemd-logind. But not enough: Apart from these, Running ultra-lightweight PDF-viewer zathura further populates my session with dbus-launch, dbus-daemon, at-spi2-registryd, and at-spi-bus-launcher, the latter launching yet another dbus-daemon. None of them have been there before, none has been invited, but they will stay around the house, giving me a creepy feeling, until I log out. I'm sure I'm missing something here...

Another example: After login, I have a systemd running with my users UID, but I have no idea what it should do (since version 206 I think I'm not supposed to use that as session manager, right?). It has a child process (sd-pam), which I failed to find documentation about.

What do they do? What is the idea behind this setup?

To clarify my perspective: In “the old days” it was enough to know that login would launch my login shell (bash, executing ~/.profile), and from that point I could continue building a session, depending on circumstances, maybe launching screen, or startx.

Improve this question
4
  • 4
    This question cannot be answered because every distro does its own stuff. Even worse, the desktop environments KDE and GNOME vastly differ which pertains to what happens after the X Windowing System has been started. Yet worse, distros change their way of doing it - you mention systemd which is relatively new. Now if you want a distribution-agnostic answer it is "the Linux kernel starts init, and everything else depends on how init is configured". This answer is as shallow as it is broad, while for every deep answer you will have to narrow down your question at least to distribution versions. Commented Jan 1, 2014 at 17:51
  • 1
    please split up your question. For example I could tell you to look for gnome-session and startkde as the "root session" process which would need more explanations. Commented Jan 1, 2014 at 18:02
  • 1
    @thorsten-staerk: “cannot be answered because every distro does its own stuff” So you're saying that I cannot make any assumption about which deamons are running? I cannot really believe that. Sorry, but splitting the question would not give the answer I'm looking for. But I'll try to rephrase “Desktop-agnostic”: I'm looking for the lowest common denominator, or the minimum set of running deamons (and justification for each of them), expected in a session. How they interact, and how this set changes with different kinds of session (is there a dbusd in a terminal session? via SSH?) Commented Jan 5, 2014 at 13:41
  • 1
    Linux is running on devices that have nothing but a LCD display. It is also running on mobile phones that do not have an AppStore and neither a camera. It is also running on a Samsung Galaxy and on mainframes. It can - making sense - use several Terabytes of RAM and it can fit into some kilobytes. I am afraid the lowest common denominator of a Linux session is Linux and you have the "freedom of choice" that is sometimes ugly to pick what else you need. For a desktop I will try to list the lowest common denominators but you will be better of asking questions about dbus instead of "everything". Commented Jan 11, 2014 at 12:34

3 Answers 3

Reset to default
8

I am so fascinated by your question that I answered it on linuxintro. Here is the answer tailored for your question:

When a typical PC with Linux like Fedora, SUSE or Ubuntu boots up the steps will be as follows:

  1. BIOS runs self-check
  2. BIOS loads the boot sector and executes it
  3. Bootloader like grub or lilo is executed
  4. Bootmenu is shown (optional)
  5. Kernel is loaded
  6. Initial RAM disk is loaded
  7. Kernel is executed
  8. Kernel executes init

  9. init executes, depending on your distro, version and configuration

    • SysV init scripts or
    • systemd or
    • upstart

The sense of all these programs is to start services like

  • dbus that allows communication between applications so that one application can call functions from another running application. This is something usually not visible to users, e.g. an application calling the window manager to put its own window into focus
  • login that allows users to log in on the CTRL_ALT_F* terminals. Login's process as seen by ps -A will in case of systemd be systemd-logind (may again vary by distribution)
  • udev that has a lot of names, e.g. for me I find it with ps -A as systemd-udevd. It assigns e.g. the device handles in /dev/ to devices that you connect, e.g. a USB disk
  • cron that will execute commands based on a time table in /etc/crontab, and also has a "@reboot" feature to start commands on boot.

10) the login process, handled by systemd will wait for a log in on a virtual terminal, one is typically reachable by pressing CTRL_ALT_F1

11) typically and by default, the init process will now start the display manager, e.g. kdm (KDE display manager) or xdm

12) the display manager will now start the graphical system. There is practically no graphical system but Xorg (hildon is for embedded devices).

13) the display manager will advice the Xorg server to display a login screen

Now the startup is complete and the computer waits for the user to log in.

14) on user log in the display manager will start a desktop environment like KDE, GNOME or XFCE4. The root process for a user's KDE session will be called startkde, the root process for GNOME will be called gnome-session, the root process for XFCE4 will be called xfce4-session

15) KDE typically starts all executable files from ~/.kde/Autostart and the .desktop files from /etc/xdg/autostart (see scheduling tasks).

16) When the user has logged in graphically and clicks on an icon to open a console, typically bash will be executed. Bash will first execute .bashrc then

17) When the user opens a log in shell this means he needs to log in via password or an authorized key. He can do this on the CTRL_ALT_F1 console or by ssh'ing to a computer, e.g. localhost. Then the .sh scripts from /etc/profile.d and .bashrc will be executed.

Improve this answer
2
  • 1
    This is a good, generic overview of the steps to start a linux system. The specific software (e.g. grub,lilo,u-boot) changes but the function is the same. I suspect you are most interested in the init process so focus on steps #8 and #9. sysvinit (/etc/inittab) is pretty much obsoleted in favor of systemd OR upstart. Both of these can run/monitor sysvinit services. Commented Oct 29, 2014 at 12:53
  • No app calls via d-bus to get it's window in focus. -- Commented Sep 19, 2016 at 7:10
-1

The answer is 42. Thorsten Staerk explained already the main problem in the comments.

To help you out to get the big picture, you need to know that Linux and Open Source software is written and maintained by millions of volunteers and companies. So, it is not easy to keep up with the growth.

On the other hand, there is a lot of documentation: the man-pages for every piece of software, a good explanation what D-Bus is, the developer mailing-lists, Google and so on. So take some years of time and read all doc's of packages you're interested in. If you need it faster, just ask some good questions at Unix & Linux.

Good luck.

Improve this answer
2
  • Knowing everything about how to operate an electric whisk tells me nothing about how the cake is made. “read all doc's of packages you're interested” — this is a rather useless answer. The documentation you mention told me what these things do. But I want to know what they are used for. “just ask some good questions” — my question is simple and straight: Where's the documentation? Commented Jan 5, 2014 at 13:47
  • 1
    Perhaps you'll need to learn how to ask to get the answer you are expect. In this case I'd like to point you to a very useful FAQ How To Ask Questions The Smart Way Commented Jan 5, 2014 at 14:03
-1

Before I give my version of the answer, let me start with a couple of definitions

Linux == 'An Operating System Kernel" Linux System == "Some kind of system built around the Linux Kernel" Session on a Linux System == "Some set of related user programs running on a linux system"

The further you get away from the kernel, the less likely any two "systems" will actually have anything in common. Which means that there isn't really any sensible definition of a "Modern Linux Session"

Frankly, the expectation that there should be some kind of overarching system documentation that gives you all the components is an expectation that just wont be met in most parts of the open source world. Open Source developers are writing programs to solve ( or re-solve! ) the specific problems they care about - so they'll just document that part it it - if that! :-)

You may have better luck with the manuals available with commercial linux distributions, however given the conservative nature of most of those, you can argue that their releases are not "modern"!

The key advice I'd give is that un a very general sense unix/linux systems are heirachical. I used to tell people that I liked nix systems because I could start with init, and from there, understand everything that was going on on a system. Systemd and friends have changed that a bit, but the basic principle is the same - start at the top and work down - the "programs making up a session" are generally those that started from the point you enter the heirachy. So, if you ssh in, you'll probably just get whatever your default shell is, as that's how ssh works. If you log in via a graphical interface, you'll get whatever is started by by your login manager, as that's how your login manager works

A lot of the desktop frameworks make this a little harder, by running various user or system level service daemons - and sometimes, these will be started on demand by a when the first program that needs them starts - look at the command line options of the programs you're running, there are quite likely options to stop this behaviour, and run the application in "bare" mode.

Unfortunatly, this does mean that "reading the individual programs documentation" is the only way to understand it all, and that there isn't a "minimum set of daemons" for a session - there's just the way a given distribution works for a given login/access method, and thats distribution, desktop, and login method specific.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.