Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Monday May 30 2016, @06:44AM   Printer-friendly
from the fed-up-with-the-UNIX-take-over dept.

The spreading of systemd continues, now actively pushed by themselves unto other projects, like tmux:

"With systemd 230 we switched to a default in which user processes started as part of a login session are terminated when the session exists (KillUserProcesses=yes).

[...] Unfortunately this means starting tmux in the usual way is not effective, because it will be killed upon logout."

It seems methods already in use (daemon, nohup) are not good for them, so handling of processes after logout has to change at their request and as how they say. They don't even engange into a discussion about the general issue, but just pop up with the "solution". And what's the "reason" all this started rolling? dbus & GNOME coders can't do a clean logout so it must be handled for them.

Just a "concidence" systemd came to the rescue and every other project like screen or wget will require changes too, or new shims like a nohup will need to be coded just in case you want to use with a non changed program. Users can probably burn all the now obsolete UNIX books. The systemd configuration becomes more like a fake option, as if you don't use it you run into the poorly programmed apps for the time being, and if they ever get fixed, the new policy has been forced into more targets.

Seen at lobsters 1 & 2 where some BSD people look pissed at best. Red Hat, please, just fork and do you own thing, leaving the rest of us in peace. Debian et al, wake up before RH signed RPMs become a hard dependency.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Informative) by Anonymous Coward on Monday May 30 2016, @03:48PM

    by Anonymous Coward on Monday May 30 2016, @03:48PM (#352655)

    but this is actually relevant to the init portion.

    No, it's not. The init system should not be concerned with user logins/session management.

    Starting Score:    0  points
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  

    Total Score:   1  
  • (Score: 0) by Anonymous Coward on Monday May 30 2016, @04:29PM

    by Anonymous Coward on Monday May 30 2016, @04:29PM (#352672)

    Its not, directly, but it is the one part of the systemd stack that is in charge of managing cgroups.

    When you log into say Gnome on a systemd distro, Gnome talks to logind, that talks to systemd-pid1, that then wraps that login in a cgroup.

  • (Score: 0) by Anonymous Coward on Monday May 30 2016, @04:33PM

    by Anonymous Coward on Monday May 30 2016, @04:33PM (#352673)

    sysv init has handled starting login daemons since forever.

    xdm/lightdm wiggled inbetween. but imho it actuyally *is* init's task to start login daemons

    • (Score: 0) by Anonymous Coward on Monday May 30 2016, @06:25PM

      by Anonymous Coward on Monday May 30 2016, @06:25PM (#352703)

      You are confusing bootup with login.

      No, init do not start login "daemons". That is done by the shell via a config file read on launch.

      All init does is set up the ttys and make sure login (its and actual program) runs on them.

      Login is in turn in charge of making sure the username and password matches, and then fire up the shell specified in for that user. Init could not give a flying fuck what is going on during all this, unless something happens and it gets handed a orphan process by the kernel.

      • (Score: 0) by Anonymous Coward on Monday May 30 2016, @07:09PM

        by Anonymous Coward on Monday May 30 2016, @07:09PM (#352721)

        Here's what a Gentoo inittab looks like:

        # Default runlevel.
        id:3:initdefault:
         
        # System initialization, mount local filesystems, etc.
        si::sysinit:/sbin/rc sysinit
         
        # Further system initialization, brings up the boot runlevel.
        rc::bootwait:/sbin/rc boot
         
        l0:0:wait:/sbin/rc shutdown
        l0s:0:wait:/sbin/halt -dhp
        l1:1:wait:/sbin/rc single
        l2:2:wait:/sbin/rc nonetwork
        l3:3:wait:/sbin/rc default
        l4:4:wait:/sbin/rc default
        l5:5:wait:/sbin/rc default
        l6:6:wait:/sbin/rc reboot
        l6r:6:wait:/sbin/reboot -dk
        #z6:6:respawn:/sbin/sulogin
         
        # new-style single-user
        su0:S:wait:/sbin/rc single
        su1:S:wait:/sbin/sulogin
         
        # TERMINALS
        c1:12345:respawn:/sbin/agetty 38400 tty1 linux
        c2:2345:respawn:/sbin/agetty 38400 tty2 linux
        c3:2345:respawn:/sbin/agetty 38400 tty3 linux
        c4:2345:respawn:/sbin/agetty 38400 tty4 linux
        c5:2345:respawn:/sbin/agetty 38400 tty5 linux
        c6:2345:respawn:/sbin/agetty 38400 tty6 linux
         
        # SERIAL CONSOLES
        #s0:12345:respawn:/sbin/agetty -L 115200 ttyS0 vt100
        #s1:12345:respawn:/sbin/agetty -L 115200 ttyS1 vt100
         
        # What to do at the "Three Finger Salute".
        ca:12345:ctrlaltdel:/sbin/shutdown -r now
         
        # Used by /etc/init.d/xdm to control DM startup.
        # Read the comments in /etc/init.d/xdm for more
        # info. Do NOT remove, as this will start nothing
        # extra at boot if /etc/init.d/xdm is not added
        # to the "default" runlevel.
        x:a:once:/etc/X11/startDM.sh

        It really looks like init is starting agetty (text console login) in addition to xdm (actually lxdm for me but could be kdm etc).

        • (Score: 0) by Anonymous Coward on Monday May 30 2016, @07:13PM

          by Anonymous Coward on Monday May 30 2016, @07:13PM (#352723)

          Ah i see, we are calling anything that is running in the background for daemons now.

          Not really any more helpful than calling everything a service.

    • (Score: 2) by sjames on Tuesday May 31 2016, @06:41PM

      by sjames (2882) on Tuesday May 31 2016, @06:41PM (#353164) Journal

      Yes, it starts them, but that's the end of the relationship. They are not expected/required to make call backs.

      If a login wants to do anything with cgroups, it should just ask the kernel itself.