Tech pill me on systemd

If Java was an init system, it would be systemd.

...

I've only ever used systemd, I started using linux a couple days after Arch introduced it, I ended up downloading an iso, and by the time I tried to install it, I couldn't follow the babbys first guide because the toolchain on my disc was deprecated. That was a very confusing day.

If I wanted to learn about service managers/PID1 stuff by trying some aside from systemd, what should I try? Is there an Arch distro that just rips out systemd and replaces it with alternatives?

It's shit and evil even though it's the same as all other loonux things.

without-systemd.org/wiki/index.php/Main_Page

Good idea, shit execution.

some bullshit on the list of 5000 other bloated bullshit programs i will never use
only difference with this one is that it makes me racist or something when I call it shit

It doesn't do one thing nor do it well.

You are incompetent

I'm sure you are willing to enlighten us all on what you mean by this. No? Incompetent.

Not an argument

Linux is not unix

First post. Every time. This time he's right. Use Google. If you HAVE to use Google, then buddy, you need systemd.

(checked)
Honestly it does.

This one understands. There is no reason.

If you ask me personally, because that's what this question is asking of, a personal opinion... I think it's cool. But it's not for everyone. If you want to learn, then it's not for you. In this case, you should learn about your system.

It's simple.

You want to have an opinion and yet you were the retard that chose Arch and chose not systemd.

I think you could see how that works out in retrospect. I use Arch and my retrospect is 20/20. You fucking idiot.

Fair. But it's not a good reason for OP. That's simply ideological.

Actually....

What are you looking for? Do you want some anonymous Chinese fingerpainter to tell you this is bad?

It's bad for certain reasons. Assuming you're an intelligent human being with opinions, it's bad because there are people that think Linux should be UNIX, but don't have the fortitude to examine BSD. At the end of the day it's ideology, and whether or not you care doesn't matter because these things find a way to infiltrate every day life.

Use what you want. Anything specific should go into the thread with the blue question mark.

Systemd is the EU of Linux.

Everything seems to be going swimmingly right now.

The execution is shit because it encompasses just too much. What business does my init system have handling udev, for instance? Why does it handle networking? Why is it also a login daemon, a time/date daemon, a hostname daemon (what, was /etc/HOSTNAME too simple?), and a replacement for the virtual terminal? Will I soon have Tony Blair invading my hard drive looking for wmd? It's just far too much.

Actually read the post you retarded faggot. Bloat is a very real problem for security and stability. Systemd is like Smart TV to me. I don't know or care what the fuck it is, I have no interest in it, and it's obviously bloated as fuck just by how the marketing department describes it, so why in the fuck should I risk installing it? I'm not arguing against systemd, I'm just explaining that it's in the list of crap I don't care about, and when I tell people it's in that list, they get triggered.

You are a fucking retard.
It does not, it has helper functions for networking and a small daemon for bootstrapping networking for small containers
You have no idea what you are talking about

See, this is the fundamental thing you retards do not understand. systemd is a collection of daemons. Some of the daemons rely on the systemd library, but all are bundled because systemd is a cathedral-esque project. Also, the vast majority of the shit people complain about are totally optional, it's up to distro maintainers to strip those binaries out if they want, and even if they don't the daemons aren't enabled by default.

It's like saying "OpenBSD is shit because it encompasses just too much in its development repository. Why does OpenBSD handle networking? Why is it also an init system, why does it have a daemon managing my devices, why is it a display server, why is it ..."

I use Arch on two computers and I've literally never had a problem with systemd

...

I had a 10GB HDD over 15 years ago which is probably a little after you were born. what kind of weird bait is this? bloat has absolutely nothing to do with file size. even the hugest applications rarely ever take more than 100MB unless it has media in it, such as games

It would probably cost more to buy a 1GB HDD today than it would to buy one with hundreds to thousands of GB ($10). You could walk around your fucking city and find a few computers in garage sales for $10-$20 and still have modern specs.

My shitdows box costed merely around $400 to build (I should have got a case for $1 instead of $40 but I was lazy), and it plays all new video games fine. And that was years ago when I bought it. I would go to garage sales and shit but I'm too afraid of getting some leftover malware. Then again maybe I shouldn't care so much since my Windows boxes are all probably full of it anyway. Thanks for the idea.

Oh, sorry, didn't mean to offend your 8MB of RAM available to handle programs alongside your pentium 1.
>>>/furry/

Now this is bait.

I love the irony of you justifying systemd by trying to compare it to an entire (well-engineered) OS.

He's comparing 2 pieces of software with cathedral design models. Are you seriously this dense?

The problem with systemd is still feature creep. Some things have no business being there.

All those things are optional.

He probably doesn't even know what "cathedral" or "bazaar" entail.
I didn't expect anything, coming into a systemd shitposting thread, yet I'm still disappointed.
I guess it's the curse, retards not knowing what they're talking about having hotshot opinions on browsers and init systems or whatever their nigger brain can faintly comprehend the function of, based on stupid shit they repeat verbatim.

It's really great software like PulseAudio, Avahi, and NetworkManager. Really, Poettering is a genius and I'm glad to have someone of his calibre fixing so many long-standing Linux issues.

You mean Manjaro? Please end yourself.

Holy fuck the idiots behind networkmanager made that shit? When I first started using niggernix I tried that and immediately switched to just using wpa_supplicant by hand never looking back.

8MB of RAM is also hard to find, and I'd assume you'd need a motherboard that supports it, so you'd need to build an entire system from scratch with all old hard to find parts which will just have less value than buying something modern

nope, that petty form of ad hominem especially when it's >poorfag he used just makes me feel like I'm arguing with a 12 year old

also, >poorfag
back to /g/, cucks

Your mental acuity is as lacking as your bank account.

I am sure all the problems with Networkmanager have been debunked on Lennart's site. NetworkManager was really important to fixing outdated Linux network management and bringing it on par with Windows.

Systemd is going to bring more of the Linux system up to par with Windows. Why do people hate systemd so much? It's making a better desktop OS. Windows has more desktop market share, so shouldn't Linux try and be more like Windows?

Hello Reddit.

+1

...

were all better and faster than it

Source?

You are a nigger.

I just wanted to make the wmd joke tbh

I was also referring to udev now being a literal part of systemd, by the way, not bringing udev up on boot.

...

No one wants to sit around going back and forth with a retard that thinks he is winning an argument by acting like a retard.

Well, GNU/Linux is something that will probably get used by a lot of people in 3rd world countries, in programs like OLPC (which gives low-tier laptops to kids), etc.
Having a bloated init system, or a bloated _anything_, is just wrong. It assumes way too much about the hardware that will run, and Poettering acts as if everyone has a bloat-compatible computer.
It does wonders for avoiding the YOTLD that we've so anxiously been awaiting, it's stopping third-world kids from getting integrated into the world, and it's holding back the freedoms we want.

In short, systemd should be called stalind.

Fuck off back to reddit

...

What "substance" have you brought to the debate, superior one?

It isn't a terrible desktop "system deamon" (whatever that means) when it works.
It isn't as robust as some other init systems (don't confuse big/bloated with robust).
It's monolithic and takes the system towards Mac OS/Windows style OS and isn't really concerned with standards. Which isn't necessarily a bad thing, but many people (including me) want something different.

Also the development focuses on desktop, which makes it less suitable for servers.

Nah.

No, it does not.

Explain the half-assed reinvention of SIGHUP then.

And if it's not focused on desktops, why would it make such a big deal over logins?
Jul 7 16:00:00 git systemd-logind: New session 2089297 of user git.Jul 7 16:00:00 git systemd: Started Session 2089297 of user git.Jul 7 16:00:00 git systemd: Starting Session 2089297 of user git.Jul 7 16:00:00 git systemd-logind: New session 2089298 of user git.Jul 7 16:00:00 git systemd: Started Session 2089298 of user git.Jul 7 16:00:00 git systemd: Starting Session 2089298 of user git.Jul 7 16:00:00 git systemd-logind: Removed session 2089297.Jul 7 16:00:00 git systemd-logind: Removed session 2089298.Jul 7 16:00:00 git systemd-logind: New session 2089299 of user git.Jul 7 16:00:00 git systemd: Started Session 2089299 of user git.Jul 7 16:00:00 git systemd: Starting Session 2089299 of user git.Jul 7 16:00:01 git systemd: Started Session 2089300 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089300 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089300 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089301 of user git.Jul 7 16:00:01 git systemd: Started Session 2089301 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089301 of user git.Jul 7 16:00:01 git systemd: Started Session 2089302 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089302 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089302 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089304 of user git.Jul 7 16:00:01 git systemd: Started Session 2089304 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089304 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089307 of user git.Jul 7 16:00:01 git systemd: Started Session 2089307 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089307 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089308 of user git.Jul 7 16:00:01 git systemd: Started Session 2089308 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089308 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089306 of user git.Jul 7 16:00:01 git systemd: Started Session 2089306 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089306 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089305 of user git.Jul 7 16:00:01 git systemd: Started Session 2089305 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089305 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089309 of user git.Jul 7 16:00:01 git systemd: Started Session 2089309 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089309 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089303 of user git.Jul 7 16:00:01 git systemd: Started Session 2089303 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089303 of user git.Jul 7 16:00:01 git systemd: Started Session 2089310 of user git.Jul 7 16:00:01 git systemd-logind: New session 2089310 of user git.Jul 7 16:00:01 git systemd: Starting Session 2089310 of user git.Jul 7 16:00:01 git systemd-logind: Removed session 2089303.Jul 7 16:00:01 git systemd-logind: Removed session 2089306.Jul 7 16:00:01 git systemd-logind: Removed session 2089302.Jul 7 16:00:01 git systemd-logind: Removed session 2089310.Jul 7 16:00:01 git systemd-logind: Removed session 2089309.Jul 7 16:00:01 git systemd-logind: Removed session 2089304.Jul 7 16:00:01 git systemd-logind: Removed session 2089305.Jul 7 16:00:01 git systemd-logind: Removed session 2089308.Jul 7 16:00:01 git systemd-logind: Removed session 2089307.Jul 7 16:00:01 git systemd-logind: Removed session 2089300.Jul 7 16:00:01 git systemd-logind: Removed session 2089299.
In case you need it hammered home, that is 2 seconds worth of log. That is systemd graciously informing me that people are in fact using the git server, and that it's creating special sessions just for them (which are completely unnecessary; gitolite handles everything after the first connect).
I realize the above is quite an unusual complaint but it's only the latest in my journey of wondering what the fuck the systemd developers were thinking.

Basically two things:

Attack surface (due to bloat and interconnected parts which were previously isolated),

Stability. Same here. The more they mingle components together, the more systembreaking shit can happen.

Third point is optional, but a lot of people don't like monopolized development of system critical components, like in systemds case.

Yes, yes it is.
judecnelson.blogspot.cz/2014/09/systemd-biggest-fallacies.html Fallacy #1
Then why does systemd with default configuration break important functionality of tmux/screen by killing their daemon after logout? Persistent sessions is one of the main reasons why people use these programs on servers, yet systemd happily breaks it because "it's a sensible behavior on desktop systems".

Who uses screen these days? Fucking nerds, just isntall systemd-libvirtd and run a vm!!

Lennart. Fucking. Poettering.

That's pretty much the only example and is pretty recent. Also, distros aren't going to ship systemd breaking tmux/screen.

Pebcak

WONTFIX

It's almost like systemd doesn't ship with sane defaults!

It's almost as if a system administrator should learn how to properly administrate their system. This means learning what needs to be configured to get the desired results of the system administrator, and applying those configurations. Who would have thought a system administrate would actually have to know how their system operates?

administrator*

Isn't a CIA agent contributing to systemd?

Anyone can contribute to any FOSS. You could be using all kinds of government code, and you would never know. Guess you should stick to proprietary software, eh?

How many computers and phones do you have with NSA SELinux active right now?

It works if you're an every day guy who happens to use Linux, as the inner workings shouldn't bother you as long as they're not sending data to corporations or the government. People who work with computers, the System Adminstrators and such, they're the only ones that (should) have problems with it. You can choose an alternative to it if you'd like, but it's not neccesary, the alternatives run just as smoothly as systemd for desktop use I'm pretty sure.

I digress at this point.

So what you're saying is that the system administrator needs to reconfigure an init system designed for desktops behave better on a server?
How else do you justify that default? Because that sure as hell isn't designed to run on a server.
Oh, and that's assuming there is some kind of configuration option to disable that logging. You've so far implied that one exists, but I have never seen anything like that documented anywhere. The closest you get is changing the systemd log level to be above "info", but those messages should have been in the debug level anyway. Setting the level to "info" will discard other potentially useful messages.

Also still waiting for your explanation of the NIH SIGHUP.

Totally agree. If you're too fucking stupid to administer a system yourself using runit or s6, you're unfit for the job.

no, that's the logging.

Well since you are completely retarded and incapable of doing an effective search on a search engine I suppose I'll spoonfeed you like the babby you are. Add StandardOutput=null to the service you want to stop logging like so:

[Service]StandardOutput=null

Holy shit that was fucking hard. Or you could just filter the logs so you don't see that part. Whatever floats your boat. Here's a tip: try actually reading the documentation instead of claiming you did when you so obviously didn't

freedesktop.org/software/systemd/man/systemd.exec.html

Okay let me just edit systemd.service... oh what's that, it doesn't exist? What a surprise!
Then there's systemd-logind, which comprises one third of the problem, and that does have a service file I can edit. But, "StandardOutput" refers to the standard output, and systemd-logind directly invokes syslog routines, bypassing stdout completely.
Thanks for the attempt, but configuring systemd sanely isn't going to be that simple.

You are fucking retarded:
/etc/systemd/system/systemd-logind.service:
.include /lib/systemd/system/systemd-logind.service[Service]Environment=SYSTEMD_LOG_LEVEL=warning

additionally, this is probably a bad idea.
you should instead filter your journald logs when you want to view them, not remove any traces of authpriv logging.
but since you're a shitty system administrator who can't read the fucking manual or use google, and really has no business touching any system because you want to eliminate logging of authpriv for potential audits after the fact, I'm not surprised that you don't understand what this is all about.

He says right after acting so smug when he thought everything was going to standard output.

So it's SYSTEMD_LOG_LEVEL? It would be nice if that were documented somewhere.
It's mentioned in a couple of man pages for other pieces of software, but only systemd and systemd-socket-activate are documented as supporting it (according to various man pages including systemd.directives(7) and the pages for each individual systemd utility).

Now, assuming that you've found some undocumented feature of systemd-logind and that it works (it's the weekend now, I'm not going to go about reconfiguring work machines), it will solve just about half the problem. There's still the same messages with slightly different phrasing coming from "systemd".

perhaps because it's not documented
Is there any query relating to removing "new session" / "session ended" logging which produces relevant results? I haven't yet found one and it's not for lack of trying.
This is a git machine. Other than root, there is one user, the git user. The git user is accessed by everyone. Everything useful is logged by gitolite, for example who actually tried logging in and what action they took, and what rules allowed or denied them access. There is also another log, wtmp, which still tells me more than systemd does and in less words. And (surprise), you're wrong about authpriv. authpriv logs are going into /var/log/secure and not going into that log. These messages are not authpriv. The information going into /var/log/secure is again much more useful, containing public key fingerprints and IPs.

But think about it rationally. There are several logins and logouts per second, all on the "git" user. With that in mind, how the fuck is such vague logging ever going to be useful for audit purposes? Suddenly I notice that things have gone up from 7 successful logins per second to 9? Realistically, how would that log ever be useful? And why do I need to know when the session is "new" versus "starting" versus "started"? This should have been debug level logging.

If I wrote a shitty little program which logged datestamped logins, repeated the log messages 3 times, and threw them into /var/log/dicks, would you install it? After all, it's valuable audit info. Or would you pass on the offer since there are already several other services doing the exact same thing in far more detail with far more useful messages?

And finally, still nobody has justified the choice to reimplement SIGHUP. Given all that's gone on so far, how can you honestly look at the situation with systemd on servers and decide that it's a better choice than the alternatives?

that's not a thing

still can't tell if trolling but if you actually think this, there's no hope for you.

Okay, since you want to be a faggot about it and flaunt your incompetence, let's show you what my thought process in solving your very difficult problem. All of this is documented by the way, I used nothing but man pages.

Let's take a look at the loglevel in journalctl for those logs. The log levels are the usual syslog log levels. 0/"emerg" through 7/"debug" according to the manual.

"SYSLOG_PRIORITY" : "6", "SYSLOG_IDENTIFIER" : "systemd-logind", ... "MESSAGE" : "New session ...",

Therefore we override the log level, by default they're logging INFO:
.include /lib/systemd/system/systemd-logind.service[Service]Environment=SYSTEMD_LOG_LEVEL=warning

You could either do that or with /etc/systemd/system/systemd-loging.service.d/environment.conf, both of these methods are in the manual.

Wow, that was fucking hard. See how easy it is to solve problems? Except, this isn't the solution to your problem.
How you really should solve this is filtering out session messages with a regex using grep by piping from journal. It works even with --line-buffered and journalctl -f. Or, you could just be specific to what you actually want to see in the journal in the first place and not have to filter out messages.

Or, you could not be incompetent, and pipe the journal to centralized logging where much better filtering capabilities are easier.
The fact that you want to eliminate something when storage is fucking cheap and have no centralized logging solution in the first place shows that you are the one who needs to git gud.

Also warning is just arbitrary. Setting it to level 5 log level would work just as well.
User sessions aren't "debug level" logging, they're info-level logging. As they should be.
The best way I'd describe "info" is "things we want to see at high volume in case an issue ever does crop up. Session lifecycle events are certainly info, login, logout, database calls, remote API calls, login failed due to something, etc.

So really, get a centralized logging solution and stop blaming systemd for your problems. The journal is doing exactly what you told it to do, and the fact of the matter is that INFO level for these events are categorically correct.

I admit I didn't bother to give enough of a fuck about your problem to do much research(I barely skimmed your post to know what the problem was), but it looks like you were thoroughly BTFO by another user here:

for your aversion to reading manuals so I won't have to. To be fair I did recommend that you filter the logs instead of trying to do the moronic thing you wish to do, so there is that.

Then why have 2 of what are possibly the most important machines in the company (read: responsible for storing a lot of the customer-visible data) been struggling at 95%+ disk usage for months, requiring frequent manual intervention?
Storage is only cheap if you can convince the higher-ups you need it. They do not value sysadmin time at all so if they can avoid allowing us to spend money (and instead make us spend time), they will. It's also hard to convince them to allow us "unnecessary" downtime. Even though they're set up in a redundant way, people have a huge aversion to downtime which won't even affect customers.
In the idealized world of sysadmins getting to spend money whenever on whatever they want, storage is cheap.

By the way, "storage is cheap" is the stupidest phrase. It should be "storage is a justifiable business expense", because there is no way that storage approaches anything I'd call cheap. Cheap is spending $5 on a shitty flash drive (which generally doesn't have much in the way of storage). Once you've gone past the price tag of anything which puts "pour homme" or other such gratuitous French on the label, you're probably not "cheap".
I have been trying to get this implemented for months but again, nobody values sysadmin time, so inevitably I will only be able to work on this for a couple of hours before someone will come up with something "urgent" or at least "more important" to keep me busy for the next few hours or days.

I realize the solution to most of this is "ditch the company" but given the pay that's a difficult choice.

If you're trying to prove a point about how simple it is to do something in systemd, being wrong about it kind of dampens that point.
Perhaps because it's not documented? The only relevant feature which is documented is the "Environment=" line, but at no point has any documentation relating to systemd-logind even made a passing mention of "SYSTEMD_LOG_LEVEL".
Just to prove a point, try searching the web with SYSTEMD_LOG_LEVEL and logind in the same query. There are mailing list discussions and forum posts and nothing else. I know that the man pages and documentation for systemd are both indexed by search engines, so that should give you an idea of the scope the search encompasses.

systemd was made by a furry

Holla Forums was made by drug addicts