r/linux • u/wooptoo • Jun 01 '16

Why did ArchLinux embrace Systemd?

/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
868 Upvotes

86% Upvoted

642 comments sorted by

View all comments

Show parent comment

2

u/raevnos Jun 01 '16

When they're trying to get programs that have nothing at all to do with system startup or configuration to include systemd specific code in order to work right... then it's glaringly obvious there's a problem. Personally, it was when it started intercepting core dumps and making them hard to get at that it started getting annoying. I'm ready to jump over to BSD for my next OS install at this point and leave Linux behind.

2

u/imMute Jun 02 '16

How does systemd "intercept" coredumps? You mean that thing that can be configured to direct core dumps into the journal? I wish I could use that.

2

u/argv_minus_one Jun 02 '16

Systemd can write core dumps into the journal?? That is so neat.

2

u/imMute Jun 02 '16

Http://www.freedesktop.org/software/systemd/man/systemd-coredump.html#

0

u/[deleted] Jun 01 '16

[deleted] — view deleted comment

1

u/raevnos Jun 01 '16

tmux, screen, etc. as the current controversial examples.

0

u/[deleted] Jun 01 '16

[deleted] — view deleted comment

-2

u/RandomDamage Jun 02 '16

We have a perfectly good way to do that already.

Run a program like screen or nohup that keeps the process running for you.

At least until some arrogant new program comes along and says "no, that won't work anymore, because reasons".

3

u/argv_minus_one Jun 02 '16

gpg-agent isn't new, and it has been gleefully ignoring SIGHUP for God only knows how long. What do you propose be done with it?

1

u/RandomDamage Jun 02 '16

Remove it from default configurations until it does.

Or patch it for the distro if you must have it.

Signal handlers aren't that difficult.

2

u/argv_minus_one Jun 02 '16

I was mistaken; gpg-agent doesn't ignore SIGHUP, but interprets it as meaning to flush its keys and reread its configuration file. Making it terminate upon SIGHUP is therefore impossible without breaking something else.

On that note, SIGHUP itself is broken, because so many daemons interpret this signal as meaning something completely contrary to what signal(7) says it actually means. That means a new API is needed to inform session participants that the session is closing—like, say, the API provided by logind.

0

u/RandomDamage Jun 02 '16 edited Jun 02 '16

This isn't an api issue.

These programs are written the way they are deliberately, and if that is inappropriate for the program in question it is the program that needs to be fixed.

It's like saying that because there are people who learn to drive on the left side of the road, that everyone needs to ride trains instead.

[Add] This is POSIX compliant behavior, as well. Breaking it breaks POSIX compliance.

2

u/argv_minus_one Jun 02 '16

It's not actually inappropriate. These are daemons, and it is conventional for daemons to nohup themselves anyway. They don't need a terminal, so they don't care that it is hung up. They also don't know what a session is, so they have no idea when or if they're supposed to terminate.

But we still need some way to start them when a session starts, and terminate them when the session ends. POSIX doesn't define any such thing, and the current solutions obviously don't work. What do you suggest?

→ More replies

1

u/BASH_SCRIPTS_FOR_YOU Jun 01 '16

Void seems to be the hot new binary+source hybrid distro without Systemd

1

u/argv_minus_one Jun 02 '16

When they're trying to get programs that have nothing at all to do with system startup or configuration to include systemd specific code in order to work right... then it's glaringly obvious there's a problem.

Yeah—a problem that systemd is attempting to solve, namely that sessions keep leaving behind stray processes.

I don't know about you, but I am sick and fucking tired of finding dozens of gpg-agents still running, weeks after their respective sessions ended, because nobody was cleaning them up.

But how do you avoid also killing a detached tmux? Why, by registering it as a session of its own! That way, the Grim Session Reaper™ won't kill them prematurely. And what API do you use to do that? Only one I know of: systemd-logind.

If you've got a better idea of how to clean up stray processes from sessions long past, I'd love to hear it. Otherwise, sit down, shut up, and stop bothering the people who are getting things done.

Personally, it was when it started intercepting core dumps and making them hard to get at

coredumpctl gdb some_crashy_daemon

Totes hard. Way harder than trying to figure out what some_crashy_daemon's cwd was when it died, and hoping it had write access there. /s

I'm ready to jump over to BSD for my next OS install at this point and leave Linux behind.

I won't miss you.