Facebook Continues Making Extensive Use Of systemd

[pal666]

Canonical almost certainly adopted systemd because they saw other big distros adopting it and their upstream distro was adopting it so it was the path of least resistance.

but surely all other distros were wrong and only canonical was right? or maybe canonical used upstart only because it was developed by canonical?

[pal666]

source

that's advertisement. in reality upstart's design is broken and even its author admits it. its design is backwards, instead of specifying dependency you have to specify triggers. this does not wok in general. it is like library specifies which programs link with it, so instead of you run bash which links in libc, you run libc and it starts bash. and if sometimes you want to run other binary, you either have to use separate libc with it, or run all binaries when you start libc. incredibly stupid isn't it?

Secondly: Mark Shuttleworth was

professional liar

[pal666]

What about the Google fallback DNS?

it works great

[pal666]

Meanwhile, Systemd and OpenRC are dependency-based init systems. This means that while they still have some kind of "events" or "system states" they react to, they will start up applications in the right order because they know what depends on what.

i don't know about openrc, but systemd will start all apps at the same time in parallel with socket activation

[Bigon]

I disagree with that choice, on a different level (if your config is fucked up it should not work, that's the only safe way to fail in this case).

I don't hold a grudge against Google DNS, it's not like "OpenDNS" is better (Cisco) or CloudFlare DNS is better on the privacy metric.

Just don't use systemd-resolved. Afaik only Ubuntu uses it of the desktop distros. Don't use Ubuntu. Problem solved.

Ubuntu is not enabling the fallback to Google DNS, this is explicitly disabled at build time. https://salsa.debian.org/systemd-tea...bian/rules#L10

[Bigon]

Well, you can twist the semantics however you like, but for all intents and purposes (and definitely for the non-technical user), the session is the login.

The language that systemd's own documentation uses, implies the same thing:

The initial assertion was that "logind controls the login" this is factually wrong. The control of the login (aka checking if a user is allowed to connect) is still the responsibility of login/xDM and PAM, this has not changed.

logind is only informed that a user has logged in and register that fact as a session

Words are important you know...

[krishnavasudeva]

It is showing no sign to stop.

[oiaohm]

As I already said, to run a normal desktop or a simple server even SysV is fine. There is nothing you can realistically run at home where you actually need something like systemd.

This is not true for most users in fact it will come clear when I answer the next bit. Sysvinit means you are missing something important.

I can't speak for Canonical, but if basically everyone adopted either Systemd or OpenRC instead of making a fork of Upstart to sidestep the Canonical CLA, there are probably some valid technical reasons too, it's not just politics. Also TruOS (FreeBSD derivative) has adopted OpenRC.

The technical reason is partly related to why sysvinit is not good enough. Upstart was using ptrace to attempt to trace what processes services started and this disrupted services and other bits ability to ptrace themselves. Systemd uses cgroups to trace what has started what and OpenRC has optional cgroup tracking. OpenRC can also effectively use BSD jails and other things on BSD platforms to trace services as well.

Consolekit the orginal don't have cgroup support and Consolekit2 is also lacking functional cgroups support.

https://github.com/ConsoleKit2/ConsoleKit2/issues/98

You can see the bugs here.

If people want to keep on using sysvinit to fix some the login session issues like users login out of session and not being able to tell what is from a long since closed login Consolekit2 need to have functional cgroup v1/v2 support..

Now is this cgroup support really optional???

https://lkml.org/lkml/2016/11/24/765

The answer is really no it not. If you are running sysvinit you fall back in kernel autogroup feature that was created so the kernel attempts to guess what processes should be scheduled with each other. If you are using a distribution mainline based kernel you will be using a scheduler that in fact to function correctly depends in the fact you have cgroups around all your services and users into sane groupings.

Anyone arguing that sysvinit/sysv is good enough fails to understand what the Linux kernel design requires from a init system. This is also why generic cross platform init systems are also lemons on Linux for generic server/desktop as well its not just sysvinit that fails to provide what the Linux kernel need to operate correctly.

Openrc has a particular code it loads for each platform it support to support the unique platform requirements. Openrc shows you how a cross kernel type init system should kind of look.

I have no problem with people being anti systemd as long as they push a solution that long term it can work. If they are pushing lets stay with sysvinit this is invalid choice long term unless it gets rewritten include the requirements of the Linux kernel and rewritten sysvinit would take you to openrc once you implemented what is in fact required. If you like the sysvinit style you need to support openrc and consolekit2 and get those developed.

Basically we need to call a spade a spade. Sysvinit like it or not is a lemon and its a lemon we used for too many years. The historic competitors to sysvinit attempted to be cross platform its so ignored Linux kernel requirements. So there are a large number of inits development with majority of them total garbage.

[Guest]

The initial assertion was that "logind controls the login" this is factually wrong. The control of the login (aka checking if a user is allowed to connect) is still the responsibility of login/xDM and PAM, this has not changed.

logind is only informed that a user has logged in and register that fact as a session

Words are important you know...

So, are you suggesting that if I apt purge systemd from my Kubuntu, SDDM will still work and I'll be able to log into Plasma? If not, the initial assertion is more or less correct.

[oiaohm]

The initial assertion was that "logind controls the login" this is factually wrong. The control of the login (aka checking if a user is allowed to connect) is still the responsibility of login/xDM and PAM, this has not changed.

logind is only informed that a user has logged in and register that fact as a session

Words are important you know...

This is more confusing than that.

Consolekit/Consolekit2 and logind both in fact create a session from PAM point of view. But this is not the only thing that is a session manager.

https://github.com/GNOME/gnome-session

You desktop environments have their own session managers that are in fact disconnected from the PAM system.

https://xkcd.com/927/

Yes it this comic in real life.

So instead of gnome/kde/xfce.... working with historic consolekit to have unified session management they went on and created their own individual differently broken session management. Logind/systemd with user services attempts to address this mess by creating a new standard.

Really we need to get all the desktop environment developers in the one project making 1 session manager they all use that is correctly connected to PAM and hopefully cross platform between Linux, BSD and others.

Yes people start arguing that logind/consolekit are not session management because they see the desktop environment session management stuff.

Please note logind/consolekit session management is the one that decides what devices a logined user can in fact access. This is why it was major security problem with consolekit not tracking users and not making sure they were logged out fully as a user that has been setting at desktop who applications are still running still could have access to mouse/keyboard and other hardware.

People complain about systemd killing all applications when user logs out by default. This starts because gnome and other desktop environment made session managers would fail to function correctly at times due to lack of tracking of what has been started. Like the X11 desktop environment fork of session management crashes and restarts without user knowing its forgot what was in fact managed. There are advantages to logind recording stuff in cgroups in case of this problem.

This are some desktop session management problems on Linux, BSD and Unix there is no point to sugar coating it.

Most people would not think that when you login into a desktop on Linux you have in fact started multi session managers because developers never worked on a unified session management. This is still like desktop environment IPC on Linux/BSD... before dbus. Things have only some what worked due to there been master session managements from either logind or consolekit.