Systemd 230 Is Upsetting Some Over Its KillUserProcess Setting

[pal666]

the "alternatives" are init system NOT system dictators.

so you too didn't read article and do not understand that we are discussing user sessions

[computerquip]

the "alternatives" are init system NOT system dictators.

[Naib]

so you too didn't read article and do not understand that we are discussing user sessions

It seems you did not read my reply in the context of what I was quoting... Try that before going full retard


Also.. LolSystemD wanting others to change their code rather than fixing the real issue...

https://github.com/tmux/tmux/issues/428

@keszybv
why don't you fix systemd instead of forcing other programs to add systemd specific code?

Or somebody could go find the actual problem @keszybz saw here - systemd/systemd#3005 - which is:

In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly.
fix that, and stop trying to make systemd break the world because somebody's gnome session doesn't currently exit cleanly.

http://thread.gmane.org/gmane.comp.t...849/focus=1856
LolSystemd...

[pal666]

It seems you did not read my reply in the context of what I was quoting...

imbecile, you was quoting my question about user sessions

Also.. LolSystemD wanting others to change their code rather than fixing the real issue...

https://github.com/tmux/tmux/issues/428

standard practice of fixing broken software. contrary to anti-systemd idiots, who propose to do nothing and wait while all non-exiting software will fix itself, smart people(systemd developers) could provide patches

[Guest]

Ultimatedly, people who hate systemd aren't using it anymore.

Most of us kinda adjusted to all the shit it comes with and after masking nearly every worthless systemd unit you get systemd-journald, systemd-udevd and maybe systemd-networkd.
At least that's how I fixed my problems with systemd, by removing everything but bare miminum.
I actually kinda like journald features, udev is kinda necessity and networkd has one of the fastest dhcp clients out there.

[SilverMachine]

i was referring to upstart or sysvinit

i havent tried nor do i know about the architecture of openrc or runit

My Slack box runs sysvinit and boots up within 12 seconds. Doesn't seem slow to me.

[davidbepo]

My Slack box runs sysvinit and boots up within 12 seconds. Doesn't seem slow to me.

does it have an ssd because if yes my laptop with one boots in 7 seconds

and if not WOW

[Naib]

imbecile, you was quoting my question about user sessions

since your special little snowflake brain is unable to follow a quote conversation no deeper than 1...

like some systemd haters said its starting to mess things, which is unfortunate cause it speedups boot process and has some advantages

the setting is logical but it should have a whitelist

Just for the record, the alternatives aren't that slow. My Raspberry Pi 1 boots almost as fast as my Haswell system although it uses runit as init.

do your "alternatives" run user sessions (which are the point of subject article)?

the "alternatives" are init system NOT system dictators.

Do you see the progression... I was refuting the point of "user sessions" as what was being discussed was INIT and the alternatives are fast... runit, openrc

standard practice of fixing broken software. contrary to anti-systemd idiots, who propose to do nothing and wait while all non-exiting software will fix itself, smart people(systemd developers) could provide patches

Standard practice when you break something isn't to get everyone else to change to your retarded breakage, its to fix your shit. SysD tried this before with the debug keyword and equally firmware loading farce they created with udev ... linus liked that didnt he...

Sure systemd are trying to "fix" problems.. some real, some perceived. But their viewport is a small desktop viewport and damned to those running anything else.


All this under the guise of "session management" and processes not being killed by GDM... Why isn't GDM getting fixed rather "requesting" proper daemon() calling application pooling in linux-specific calls (remember tmux isn't just a linux application).



Just checking how my Openbox launched (via lightDM) handles "sessions" while also ensuring a tmux session exists:
logged in as root in a VT and ps - u ... pre-quitting openbox

  PID TTY          TIME CMD
 4546 ?        00:00:18 openbox
 4557 ?        00:00:00 dbus-launch
 4558 ?        00:00:00 dbus-daemon
 4560 ?        00:00:00 at-spi-bus-laun
 4565 ?        00:00:00 dbus-daemon
 4567 ?        00:00:00 at-spi2-registr
 4572 ?        00:00:00 dbus-launch
 4573 ?        00:00:00 dbus-daemon
 4587 ?        00:00:00 sh
 4590 ?        00:00:00 sh
 4594 ?        00:00:00 sh
 4602 ?        01:48:04 DiscordCanary
 4603 ?        00:04:18 skype
 4604 ?        00:00:00 polkit-gnome-au
 4611 ?        00:00:00 gvfsd
 4614 ?        00:26:33 pulseaudio
 4619 ?        00:00:00 DiscordCanary
 4660 ?        00:00:00 urxvt
 4675 ?        00:02:04 conky
 4699 ?        00:00:04 DiscordCanary
 4705 pts/0    00:00:00 bash
 4730 ?        00:00:23 DiscordCanary
 4769 ?        00:00:00 bash
 4770 ?        00:00:12 lxpanel
 4779 ?        00:00:00 bash
 4780 ?        00:00:00 tee
 4812 ?        00:00:00 gvfs-udisks2-vo
 4885 ?        00:01:59 steam
 4889 ?        00:00:00 menu-cached
 5029 ?        00:00:00 steam
 5030 ?        00:00:11 steamwebhelper
 5033 ?        00:00:00 steamwebhelper
 5353 ?        00:00:00 gconfd-2
 5486 ?        00:00:32 steamwebhelper
 7179 ?        00:00:00 urxvt
 7180 pts/1    00:00:00 bash
11590 ?        00:00:00 xdg-open
11654 ?        00:02:42 chrome
11661 ?        00:00:00 cat
11662 ?        00:00:00 cat
11665 ?        00:00:00 chrome
11666 ?        00:00:00 nacl_helper
11669 ?        00:00:00 chrome
11754 ?        00:00:58 chrome
11765 ?        00:00:00 chrome
11781 ?        00:00:01 chrome
11860 ?        00:00:25 chrome
11866 ?        00:00:12 chrome
11880 ?        00:00:07 chrome
11882 ?        00:00:00 chrome
11887 ?        00:00:11 chrome
11892 ?        00:00:00 chrome
11907 ?        00:00:17 chrome
11972 ?        00:00:25 nacl_helper
12017 ?        00:00:04 chrome
12022 ?        00:00:02 chrome
12024 ?        00:00:01 chrome
12027 ?        00:00:04 chrome
12784 ?        00:00:05 chrome
13018 ?        00:00:10 chrome
13042 ?        00:01:04 chrome
13390 ?        00:00:45 chrome
13439 ?        00:00:17 chrome
13869 ?        00:00:10 chrome
13920 ?        00:00:00 urxvt
13921 pts/2    00:00:00 bash
14334 pts/2    00:00:00 tmux
14336 ?        00:00:00 tmux
14337 pts/3    00:00:00 bash

post-quitting openbox

  PID TTY          TIME CMD
14336 ?        00:00:00 tmux
14337 pts/3    00:00:00 bash

OMG the user processes have been cleaned... a non-issue for a sane setup. But sure carry on advocating stubs being placed into applications that correctly setsid and daemon calls... ignoring poor high system architecture fails... You go girl, you carry on pushing stupid, like the whole /usr farce and initramfs..

Validating what a session manage, daemon manager, desktop manager is requirements 101 and YET Systemd developers and advocates consistently overlook at it and when poor design decisions come to fruition RATHER than correcting their mistakes they expect others to change.
If things need to change then change, but to facilitate the perpetuation of retarded design decisions (in this case.. systemd, dbus, gdm...) is taking liberties too far.

[cj.wijtmans]

does it have an ssd because if yes my laptop with one boots in 7 seconds

and if not WOW

yeah with ssd/uefi/systemd/plasma i boot within one second, on a cold boot 2-3 seconds. Although my kernel is very custom and lean. Still a "systemd hater" as you people call it.

[boltronics]

That whole boot-up time argument... the one person I know in person who actually used that as an argument for systemd saw me boot from a USB stick with sysvinit on Debian wheezy, and accused me of using a fast USB3 thumb drive to get the boot speed I had. Nope, just plain old USB 2 thumb stick I got for free at a dev conference at some point (with the Microsoft TM on it - so it's well suited for a bootable Debian install!).

Even if on old systems with mechanical HDDs where a few seconds might possibly be saved... it's not an argument for the massive (and always increasing) scope systemd is trying to fill. I too am in the process of tinkering with GuixSD, and expect to switch when it's more mature - probably late this year or next year.