Announcement

Collapse
No announcement yet.

Systemd Support For Managing User Sessions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Systemd Support For Managing User Sessions

    Phoronix: Systemd Support For Managing User Sessions

    Intel has begun work on systemd unit files for managing the user session with early unit files being available for KDE and other desktop environments...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Nice!

    Why can't there be a freedesktop.org standard for describing user sessions.
    It would be really handy to make this DE independent.

    Comment


    • #3
      No thanks, I like my system to behave in the Unix way, one tool for one purpose. If I want to have monolithic applications that handle all thinkable things using a binary configuration file I can load my Vista.

      Comment


      • #4
        Originally posted by TobiSGD View Post
        No thanks, I like my system to behave in the Unix way, one tool for one purpose. If I want to have monolithic applications that handle all thinkable things using a binary configuration file I can load my Vista.
        There are still human readable files used in the configuration of systemd. What are you on about?

        And actually i think its quite cool that we are about to have a standardized way of doing things rather than have every odd distro implement stuff their own way.

        Comment


        • #5
          I'm not sure if I like the idea of systemd fiddling with user modifiable files. If they're not careful it could open up systemd to a lot of new security vulnerabilities. Or what if some badly formated user session files causes systemd to crash/hang?
          I'm also doubtful if using systemd would lead to a more standardized way of handling user sessions. Not even all Linux distros use systemd and any worthwhile standard for user sessions should also take the other unix-siblings into account. I highly doubt that BSD,IOS and Solaris are going to abandon their current startup systems, but you might get them to offer optional support for a new DE-agnostic user session manager/standard.

          I do like the idea of a DE-agnostic session manager as that should allow you to add session management to some of the older wm's like icewm, enlightenment etc. I know it is possible to use the session managers from Gnome or KDE but most of the time you'll either end up with loading the full Gnome/KDE DE just rendered with icewm or you'll end up destroying your normal Gnome/KDE session that you want for those time when you really want the full Gnome/KDE DE.
          The session-manager from Xfce3 was able to run with just about any windowmanager you'd want but that's deprecated software now.

          Icewm with full session management was pretty nice though. I'm almost tempted to grab the source for xfce3-session and compile it.
          Enlightenment would also be a really nice DE with proper session management.
          Last edited by a7v-user; 26 June 2012, 08:31 AM.

          Comment


          • #6
            Originally posted by TobiSGD View Post
            No thanks, I like my system to behave in the Unix way, one tool for one purpose. If I want to have monolithic applications that handle all thinkable things using a binary configuration file I can load my Vista.
            +1 some people are envisioning systemd with more functionalities it should ever-ever-ever have. if we want to standarize user sessions on linux, LSB could be the place to do it ... systemd clearly is not

            The session-manager from Xfce3 was able to run with just about any windowmanager you'd want but that's deprecated software now.
            Never checked it, but ... what about lightdm? is it an option to xdm?

            Comment


            • #7
              Originally posted by TobiSGD
              If I want to have monolithic applications that handle all thinkable things...
              ...I'd install the Linux kernel!

              *Badoom tssch!*

              Comment


              • #8
                Originally posted by Wingfeather View Post
                ...I'd install the Linux kernel!

                *Badoom tssch!*
                The Linux kernel handles the hardware and scheduling, that is its single purpose and its a job that is done pretty well by the kernel. No one wants to make the kernel to handle user logins, starting/stopping the daemons or take care of session management.
                Why are people expecting that when you take a working system, replace all the working parts with the brainfart of Lennart Poettering that this would be a good idea? It is one thing to go and replace the init system, may it be BSD-like, System V, Upstart or whatever, with another init system like systemd. Then we have one tool that takes care of one function, the Unix way to do things. But why should the same application take care of system logging, user sessions and whatever the crew about Poettering can think of?
                That doesn't make any sense. I can only hope that Pat Volkerding keeps his sane mind and will not anytime soon (better: at no time) integrate this crap into Slackware.

                Comment


                • #9
                  I like systemd myself, but I can certainly see why some people would not.

                  I'm running a recent git snapshot of it on Kubuntu 12.04 now, and it works fine -- though admittedly I had to write a wrapper for /sbin/initctl. I was never a fan of Upstart so I was keen to try this out, but I just can't get Fedora to grow on me. Also the Kubuntu crew are bros.

                  Do correct me where I'm wrong, but I believe systemd can run either as a system instance (PID 1), or as a user instance with only the privileges the user itself holds. Much like dbus.
                  Code:
                  $ [B]systemd --help[/B]
                  systemd [OPTIONS...]
                  
                  Starts up and maintains the system or user services.
                  
                    -h --help                      Show this help
                  [...]
                       --system                    Run a system instance, even if PID != 1
                       --user                      Run a user instance
                  [...]
                  
                  $ [B]psgrep systemd[/B]
                  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
                  [B]root[/B]         [B]1[/B]  0.0  0.0  41184  3364 ?        Ss   Jun26   0:01 [B]/bin/systemd[/B]
                  root       224  0.0  0.0  77896  2860 ?        Ss   Jun26   0:07 /lib/systemd/systemd-journald
                  root       245  0.0  0.0  28672  1664 ?        Ss   Jun26   0:00 /lib/systemd/systemd-udevd
                  root       723  0.0  0.0  30492  1544 ?        Ss   Jun26   0:00 /lib/systemd/systemd-logind
                  102        741  0.0  0.0  24832  2348 ?        Ss   Jun26   0:05 //bin/dbus-daemon --system --address=systemd: --nofork --activation=systemd
                  [B]zorael[/B]   [B]17912[/B]  0.0  0.0  33352  2056 pts/1    S+   15:31   0:00 [B]systemd --user[/B]
                  I have yet to use it in its user instance at all; I just ran it now to copy its ps entry here. I'll probably toy around with these KDE user units tomorrow.


                  In systemd's defense, all configuration files for services/mounts/sockets/timers/... ('units') are still humanly readable -- but they are not shell scripts, just like upstart's conf files aren't. You can still have several entries of ExecStartPre= commands that, when executed in sequence, halt (or not) the entire unit if they exit with errors. Like '/usr/bin/stuff --check-config', or simply '/bin/mkdir -p /run/lock/stuff'.

                  What systemd does make binary is a set of small helpers and daemons that cover certain basic and 'obvious' things. Instead of calling a shell script to put on your socks, you get it in compiled C. Luckily they're not incorporated into one huge /bin/systemd; most have unit files like every other service, ergo you can disable them like any other service. Some just seem to be internal helpers, some seem to be for shell scripting (?), some are definitely CLI tools.
                  Code:
                  systemd-ac-power                 # does udev magic and returns 0 if on AC
                  systemd-analyze                  # cheapo bootchart. "[...] determine system boot-up performance of the current boot."
                  systemd-ask-password             # "[...] query a system password or passphrase from the user, using a question message specified on the command line. [...] The purpose of this tool is to query system-wide passwords -- that is passwords not attached to a specific user account. Examples include: unlocking encrypted hard disks when they are plugged in or at boot, entering an SSL certificate passphrase for web and VPN servers."
                  systemd-binfmt                   # it looks like it registers extra executable types and makes the kernel automagically call wrappers for them if need be? so ./file.exe would be run via Wine
                  systemd-cat                      # cats piped text or called args to the journal, see systemd-journald below
                  systemd-cgls                     # 'cgroup list'
                  systemd-cgroups-agent            # cgroup release agent
                  systemd-cgtop                    # 'cgroup top'
                  systemd-coredump                 # saves a coredump if systemd crashes
                  systemd-cryptsetup               # sets up encrypted block devices as you'd expect
                  systemd-cryptsetup-generator     # "[...] translates /etc/crypttab into native systemd units"
                  systemd-delta                    # shows diff output of how user-modified units in /etc/systemd/{system,user} override those in /lib/systemd/{system,user}
                  systemd-detect-virt              # "[...] detects execution in a virtualized environment. It identifies the virtualization technology and can distuingish full VM virtualization from container virtualization."
                  systemd-fsck                     # fsck logic at boot (at least)
                  systemd-fstab-generator          # "[...] translates /etc/fstab [...] into native systemd units"
                  systemd-getty-generator          # starts and manages ttys, be they virtual or console
                  systemd-hostnamed                # "[...] mechanism to change the system hostname."
                  systemd-inhibit                  # "[...] used to execute a program with a shutdown, sleep or idle inhibitor lock taken. The lock will be acquired before the specified command line is executed and released afterwards."
                  systemd-initctl                  # "[...] implements compatibility with the /dev/initctl FIFO file system object, as implemented by the SysV init system."
                  systemd-journald                 # think syslog; "[...] system service that collects and stores logging data. It creates and maintains structured, indexed journals based on logging information that is received from the kernel, from user processes via the libc syslog(3) call, from STDOUT/STDERR of system services or via its native API."
                  systemd-localed                  # "[...] mechanism to change the system locale settings, as well as the console key mapping and default X11 key mapping."
                  systemd-loginctl                 # "[...] introspect and control the state of the login manager.", see below
                  systemd-logind                   # login manager that I have yet to learn to use
                  systemd-machine-id-setup         # generates the /etc/machine-id file which "contains the unique machine id of the local system that is set during installation. [...] Programs may use this ID to identify the host with a globally unique ID in the network, that does not change even if the local network configuration changes."
                  systemd-modules-load             # modprobes modules listed in /etc/modules-load.d/*.conf, like Upstart's module-init-tools does with /etc/modules
                  systemd-multi-seat-x             # in preparation for multiseat; "this binary will go away as soon as X natively supports display enumeration with udev in a way that covers both PCI and USB."
                  systemd-notify                   # "[...] may be called by daemon scripts to notify the init system about status changes. It can be used to send arbitrary information, encoded in an environment-block-like list of strings. Most importantly it can be used for start-up completion notification."
                  systemd-nspawn                   # "[...] used to run a command or OS in a light-weight namespace container. In many ways it is similar to chroot, but more powerful since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and the host and domain name."
                  systemd-quotacheck               # filesystem quota logic
                  systemd-random-seed              # "[load] and save the system random seed at boot and shutdown"
                  systemd-readahead                # readahead implementation (systemd-readahead{,-collect,-done,-drop,-replay})
                  systemd-remount-fs               # "[...] early-boot service that applies mount options listed in fstab"
                  systemd-shutdown                 # shutdown logic
                  systemd-sleep                    # suspend logic
                  systemd-sysctl                   # configures sysctl parameters
                  systemd-system-update-generator  # "[...] automatically redirects the boot process to system-update.target if /system-update exists."
                  systemd-timedated                # "[...] used as mechanism to change the system clock and timezone, as well as to enable/disable NTP time synchronization."
                  systemd-tmpfiles                 # "[...] creates, deletes and cleans up volatile and temporary files and directories" as per configuration
                  systemd-tty-ask-password-agent   # "[...] handles password requests of the system, for example for hard disk encryption passwords or SSL certificate passwords that need to be queried at boot-time or during runtime."
                  systemd-udevd                    # udev! http://lwn.net/Articles/490413
                  systemd-update-utmp              # "[...] writes SysV runlevel changes to utmp and wtmp, as well as the audit logs, as they occur."
                  systemd-user-sessions            # "[...] controls user logins. After basic system initialization is complete it removes /run/nologin, thus permitting logins. Before system shutdown it creates /run/nologin, thus prohibiting further logins. At the same time it also kills all user processes, so that system shutdown may proceed without any remaining user processes around."
                  systemd-vconsole-setup           # sets console font and keymap
                  It all falls under the systemd project, but not all of that is /bin/systemd. So it's not a huge, monolithic binary blob trying to do everything -- they just rewrote some core stuff of the init process (eg. loading/saving random seed and modprobing modules) in C so as to stop needing shell scripts for those, and avoid the overhead those incur. Even if every distro were to immediately switch to systemd, you can still disable all of this and keep to conventional scripts through its sysv init.d compatibility. Inarguably scripts are easier to debug.

                  Admittedly, some parts of systemd reimplement existing solutions, though. systemd-readahead does away with ureadahead, timer units do away with cron, systemd-analyze does away with bootchart, and some others. At least it's modular so I can opt to disable the bits I don't want.

                  I'm not a packager, but I'd say it would sort of make sense to split these up a bit, so you'd have systemd, systemd-daemons and systemd-tools or so, to make it all a bit less intimidating.

                  Comment


                  • #10
                    Originally posted by TobiSGD
                    The Linux kernel handles the hardware and scheduling
                    Yes it does. In addition to the huge number of other things it does. It handles all networking (including firewalling/bridging/routing), filesystems, all that KMS stuff, the ALSA layer, crypto services... I am sure there's loads more.

                    The Linux kernel is a massive blob that does all kinds of things. So let's at least be consistent. If you want to attack this as a principle you can't just cherry-pick systemd because people think it's cool to hate whatever Lennart Poettering has been involved with.

                    Comment

                    Working...
                    X