For the last year and a half I've really tried to like it, I've tried to overlook its issues in the hope they will eventually get fixed... But the developers just keep creating more.

Version 240 is necessary because of several vulnerabilities found in things like resolved and tempfilesd. Note that I read the former was caused by not following best coding practices for DNS applications.

So, the first 240 issue I ran into was this: Login to the console, startx, ctrl-alt-backspace and I get hit with a console login prompt. Yet other console sessions seem to be okay. (Alt F2, etc.)

I start searching for answers and find this. It seems environmentd or whatever stopped carrying DBUS_SESSION_BUS_ADDRESS in the shell. And... Okay, that appears to be a misunderstanding with the dbus guys.

So, I pulled the fix from git and rebuilt systemd. It's still happening. Maybe it's my system? So, I upgrade my Arch system from 239 to 240 and... Yep, repeatable on ArchLinux so this is clearly a 240 problem.

I dig deeper and look at the system log. I had already tried the user and xserver logs at the beginning of this and nothing looked abnormal. What I noticed there is baffling... systemd-logind is killing getty when you startx from the shell.

W.T.F.

Look, I don't want to sound like the grump who just grumbles about change. I understand something new was needed because event handling, hotplug, etc. etc. But why does this change need to be so beastly? Why do they keep breaking established behavior? Service manager or not, does networking stuff belong there? Does the system log? Importd? Coredump? Will this project ever be feature-complete? Even svchost.exe doesn't go this far on Windows.

Long story short, If you upgrade to systemd-240, (current LFS svn) when you use startx logind will now ask you to login after the XServer exits. And if you use: gnome, xfce, mate or kde the entire system will puke if you don't patch in the backport of the dbus session address.

I know that was a rant. But I'm really trying to accept systemd and it seems absolutely determined to make me hate the damn thing.

I wonder what [rant] tags would format as should jeremy acquiesce ...

1 members found this post helpful.

Yes, it's because they're "... not following best coding practices..." You said it yourself.

I switched away from systemd infected systems some time ago now. Mine was because I couldn't read the log files, simply, when x wouldn't start, for numerous reasons over time, mostly to do with new hardware, graphics card drivers, wifi cards, usb-mobile modems and usb-audio boxes at different times.

I was using Mageia, before that Mandriva.

I hope you find peace.

Not really. That too was a false claim by the systemd cabal. systemd was promoted through alternating use of ad-hominem and appeal-to-novelty, a combination which was effective. Misdirection and lying also took (and takes) place in that it is often referred to as an init system. it is not one, though it includes one. However, systemd was not the only alternative, there were many options in regards to just init systems. Nor was there such a need for a rush to jump in with both feet before evaluating the waters -- unless the only goal was to encumber distros with systemd by avoiding discussion of the boatloads of design and implementation flaws. That haste was also a false claim made by the systemd cabal.

My own speculation as to one long term purpose of systemd is that it was to serve as a vehicle for inserting DRM between the kernel and the user-space. However, now that Linus Torvalds is comfortably out of the way, there has been movement in getting it directly into the kernel itself.

The other apparent long term purpose of systemd is that is serves to pick up where M$ left off in regards to decommodifying GNU/Linux and locking it under the control of a single vendor. The Halloween Documents, which turned 20 this last autumn, go into detail about how that strategy works.

Support one of the distros without systemd. There are still some of those. A cascade of damage rippled through hundreds of distros when the systemd cabal was able to torpedo Debian, since hundreds are based on it either directly or indirectly and they were all forced into systemd. Few depended distros have swapped to Devuan but if you need a drop-in replacement for Debian, there is Devuan which allows a wide choice of init systems but defaults to SysV. Then again systemd is not an init system.

But back to your rant, I presume you've seen the latest systemd contribution to the community:
https://www.qualys.com/2019/01/09/sy...ystem-down.txt

3 members found this post helpful.

When I speak of the event interfaces, etc. What I am really referring to is the good points made by Dave Zarzycki in his Google Tech Talk about Apple's launchd in 2007. That presentation is what Lennart based his systemd design on. That said, even launchd doesn't have the scope of systemd.

I just don't understand why this has to be such a brutal shoehorn of a change. Progress could have been made without using a sledgehammer to do it. And now the bugs, the upgrade problems and the vulnerabilities. This thing could have been received well if it didn't go around bludgeoning the community.

As for this being some sort of conspiracy, I'd be more open to believe that if opaque binaries were somehow included. I think what happened is that they simply sold the most marketable product in the world: convenience. People wanted features and APIs, and this group started to produce that. Additionally, they created a product that took a lot of configuration work off the backs of distro developers. It does a lot of things out of the box. Unfortunately, things like limiting scope, prudence and care seem to be lost on them.

It would not have been accepted in any way, shape, or form without the sledgehammer. My point above is that progress is not the goal of systemd.

No secret conspiracy is involved here. All parties, from Lennart to Red Hat Inc to M$ have been out in the open about what's going on. "cabal" is Lennart's own description. Red Hat has stated its goals and methods and acted on them for years. Even M$ eventually admitted to the "Halloween Documents".

The way the systemd project operates, with copious amounts of poor, uncommented code, means that opaque binaries are not needed and that the same effect can be achieved under a FOSS license. It's just written in such a way that not only are heavy C skills are needed but also an enormous time commitment to delve into the code. Only a large corporations have enough resources to sponsor that, it's beyond small players and volunteers, no matter how willing. For all practical purposes, the code is beyond reach. If it were well-commented, cleanly designed, and well-written, then many people or companies could join in. As it is now? Not so many.

Thanks for the launchd video. I think I've listened to it before but will queue it up for review shortly.

1 members found this post helpful.

To slightly misquote HHG "It's superficial design flaws serve to hide it's fundamental design flaws."

Don't use it never will.

3 members found this post helpful.

I was, in the past, very much against it. Then, not wanting to be a negative curmudgeon, I tried to give it the benefit of the doubt and have been using it for the last couple years... though I use a much modified configure line that turns of: resolved, networkd, cordumpd, importd, efi, tpm, hibernate (a couple of others) and changes things like the default nntp servers. But, every time everything's running smoothly I hear about another vulnerability and when I update things break. Things that should never break... like exiting an X session started from the console via startx and finding yourself at a login after you type 'exit' in the GUI.

so maybe that is why this one distro I was trying was crapping out on me, I didn't look to see the number that comes up on boot, but here I wasn't using startx, it set itself up for gui login then getting stuck or some such thing when I logged in, it was not doing what it was suppose to doing, whatever that was I forget, I do remember, I ctrl-alt-backspace and every time it kicked me out to a login prompt, instead of the login manager, so I logged in and there it was, still the black screen (CLI / term), so I just startx to see what would happen it hung up for a bit then killed the xserver, and needless to say I deleted that iso and moved on to a different distro to check out.

Here is what's going on...

Jan 10 10:45:30 mylaptop /usr/bin/gpm[472]: *** info [mice.c(1990)]:
Jan 10 10:45:30 mylaptop /usr/bin/gpm[472]: imps2: Auto-detected intellimouse PS/2

I type startx...

Jan 10 10:45:31 mylaptop login[637]: pam_unix(login:session): session closed for user <me>
Jan 10 10:45:31 mylaptop systemd[1]: getty@tty1.service: Succeeded.
Jan 10 10:45:31 mylaptop audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 10 10:45:31 mylaptop systemd[1]: session-3.scope: Succeeded.
Jan 10 10:45:31 mylaptop systemd[1]: getty@tty1.service: Service has no hold-off time (RestartSec=0), scheduling restart.
Jan 10 10:45:31 mylaptop systemd[1]: getty@tty1.service: Scheduled restart job, restart counter is at 2.
Jan 10 10:45:31 mylaptop systemd[1]: Stopped Getty on tty1.
Jan 10 10:45:31 mylaptop kernel: audit: type=1131 audit(1547135131.296:48): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

I exit the xterm window to stop the XServer...

Jan 10 10:45:31 mylaptop systemd-logind[462]: Session 3 logged out. Waiting for processes to exit.
Jan 10 10:45:31 mylaptop audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 10 10:45:31 mylaptop audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 10 10:45:31 mylaptop systemd[1]: Started Getty on tty1.
Jan 10 10:45:31 mylaptop audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 10 10:45:31 mylaptop systemd-logind[462]: Removed session 3.
Jan 10 10:45:31 mylaptop kernel: audit: type=1130 audit(1547135131.300:49): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 10 10:45:31 mylaptop kernel: audit: type=1131 audit(1547135131.300:50): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 10 10:45:31 mylaptop kernel: audit: type=1130 audit(1547135131.300:51): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=getty@tty1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 10 10:45:36 mylaptop login[720]: pam_unix(login:session): session opened for user <me> by LOGIN(uid=0)
Jan 10 10:45:36 mylaptop kernel: audit: type=1006 audit(1547135136.113:52): pid=720 uid=0 old-auid=4294967295 auid=1001 tty=tty1 old-ses=4294967295 ses=4 res=1

And... I'm forced to login again.

Jan 10 10:45:36 mylaptop systemd-logind[462]: New session 4 of user <me>.
Jan 10 10:45:36 mylaptop systemd[1]: Started Session 4 of user <me>.
Jan 10 10:45:36 mylaptop login[720]: LOGIN ON tty1 BY <me>
Jan 10 10:45:36 mylaptop /usr/bin/gpm[472]: *** info [daemon/processrequest.c(42)]:
Jan 10 10:45:36 mylaptop /usr/bin/gpm[472]: Request on 6 (console 1)
Jan 10 10:45:36 mylaptop /usr/bin/gpm[472]: *** info [daemon/disable_paste.c(28)]:
Jan 10 10:45:36 mylaptop /usr/bin/gpm[472]: disabling pasting per request from virtual console (1)
Jan 10 10:45:36 mylaptop /usr/bin/gpm[472]: *** info [daemon/processrequest.c(42)]:
Jan 10 10:45:36 mylaptop /usr/bin/gpm[472]: Request on 6 (console 1)

Again... W.T.F. Why was it necessary to change this? Can anyone offer some rationality to jacking with userspace this way?

3 members found this post helpful.

Moin,

Ok, i also do not like systemd very much. In the past i built some LFSes with systemd but then returned to LFS with sysvinit, for the usual reasons. So, who forces you to use systemd if you don't like it? Especially on LFS, where you have the choice.
Of course, things will get harder, if the LFS/BLFS guys would decide to drop the sysvinit version of the books.

Gruss
WK

I have been using it because, in spite of all its faults, there are some things that systemd does right. Unfortunately, that nice box of tricks comes with a bag of dog poop as well, poop that's difficult to scrape off the rest of it. If the project just had a sane scope and didn't absorb things like udev... That would have made things so much better.

I started using it mainly because it handled running on a laptop better. Suspend, hibernate, hotplug dhcpcd without creating a new config file when I hook up Ethernet or a USB cell modem, rfkill, backlight; all that stuff works properly, out of the box, on systemd. But, journald, µhttpd, networkd, resolvd, coredumpd, importd, rpm, efi, tpm, ntpd, crond, changing su behavior? All of that could have been separate from a cgroup/services/init/session package and still used systemd APIs. As I think of it, if it came in two parts: One being init/services (systemd) with parallel startup and supported both service style config files and classic init scripts. With the second package being support for cgroups/session (logind) that would have been ideal. Servers probably still wouldn't have need of it, but maintaining the optional nature of the whole thing would still have seen it used by most desktop distros because, let's face it, that's where it could have fixed a lot of problems. Instead, it fixed a few, and created a plethora of new ones...

I was using a LFS-8.3 system built with systemd. To be fair i had zero issues with it. For the new year i just built a new system (lfs-svn Jan1, blfs-svn Jan10) and used traditional systemV instead. One big reason for me to switch: i don't want to include PAM complexity (for logind) and i have no need of cgroup/namespaces support in the kernel. The parallel service startup doesn't benefit me as i have very, very few services that need to start at boot.

LFS-8.3 barely touches systemd. You can still configure stuff. Over on Mint, it's taken over every &$%£@$! thing. It has a hand in grub, booting, networking, and no clue how to configure it. It's like systemd; it wants to take over - until they discover it's full of holes.

SERIOUS EDIT: It's like SELINUX; it wants to take over - until they discover it's full of holes.

Built LFS & BLFS systemd for version 7.9, 8.0, 8.1, & 8.2.
So far so good.

Cause I'm so busy, I don't have time to built LFS & BLFS version 8.3
I will wait for version 8.4