You must log in or # to comment.
“I hate systemd, it’s bloated and overengineered” people stay, perched precariously on their huge tower of shell scripts and cron jobs.
huge tower of shell scripts and cron jobs.
That’s bloat. I start all my services manually according to my needs. Why start cupsd BEFORE I need to print anything?
thats what systemd sockets are here for
or inetd!
“I hate systemd, it’s bloated and overengineered”
And built poorly by people who don’t work well with others and then payola’ed onto the world.
people stay, perched precariously on their huge tower of shell scripts and cron jobs.
Fucking UNIX is shell scripts and cron jobs, skippy. Add xinetd and you’re done.
yeah I just hate the move away from flat text files honestly. Its one thing I did not like about windows NT with the registry. databasing up the config.
Which part of systemd’s config is not text-based? The only “database” it uses for configuration is the filesystem
well its text but its just a bit more complex of a flat file. like yaml. like one thing I really liked about cisco ios was how the config file the commands where pretty much the same thing. granted thats not unix but its the simplicity level that is ideal to me.
systemd config is inspired by INI, with section headers and key-value pairs. It doesn’t get much flatter than that. It doesn’t compare to YAML or JSON.
ini as in windows init files?
Yes
If systemd was only managing services there would be less opposition. People opposed don’t want a single thing doing services and boot and user login and network management and…
Are they also opposed to coreutils being a single project with dozens of executables doing different things?
IDK, ask them. There are some in this thread. I’m addressing the strawman argument that people against it are luddites set in their ways over their beloved cron jobs.
Wait until you learn about
debhelper.If you use a debian-based system, unless you have actively looked at the DH source, the one thing that built virtually every package on your system, you do not get to say anything about “bloat” or “KISS”.
DH is a monstrous pile of perl scripts, only partially documented, with a core design that revolves around a spaghetti of complex defaults, unique syntax, and enough surprising side effects and crazy heuristics to spook even the most grizzled greybeards. The number of times I’ve had to look at the DH perl source to understand a (badly/un)documented behavior while packaging something is not insignificant.
But when we replaced a bazillion bash scripts with a (admittedly opinionated but also stable and well documented) daemon suddenly the greybeards acted like Debian was going to collapse under the weight of its own complexity.
Oh yes, fuck dh with a rusty pole. I’ve had to paclage some stuff at work, and it’s a nightmare. I love having to relearn everything on new compat levels. But the main problem is the lack of documentation and simple guidelines
[ *] (3 of 3) A stop job is running for User Manager for UID 1000... (1m12s / 3m)# nano /etc/systemd/{system,user}.conf ---- DefaultTimeoutStopSec=10sYou’re welcome.
OH LOOK A CONF FILE TO EDIT.
Full circle, bitches.
What the fuck it even means for a stop job to run?
Systemd is trying to stop a service. To do an action to a service (or any unit), it runs a job. The job to stop a service is called a stop job. Once the stop job is taken off the job queue, the stop job is running.
The method of stopping a service is configurable, but the default is to send a kill signal to the MainPID, then wait for the process to exit. If it doesn’t, after a timeout, the kill is reattempted with a harsher signal.
So its the units to blame
What is the default of the default?
Dunno, but looks at
man service.unitI think)
Type
rebootinto an SSH session and play everyone’s favorite game show…WILL IT ACTUALLY DO IIIIIIIIIIIIIIT
I will take OpenRC to my grave
I’m more of a runit guy, but I started using Alpine recently, and I have to say, openrc is also pretty nice!
Unit files, sockets and systemctl
Stop it Patrick, you’re scaring him!
What “scares” me the most is the journal… for some reason it takes too long to get specific unit logs, and should anything break down in it, there is no way for me to fix it. Like logging has been solved forever, and I prefer specific unit logs to the abomination of journalctl.
But like unit files are everywhere, and systemctl at its core is a nice cmd utility.
The thing with journalctl is that it is a database. Thus means that searching and finding things can be fast and easy in high complexity cases but it can also stall in cases with very high resource usage.
Thing is that they could have preserved the textual nature and had some sort of external metadata to facilitate the ‘fanciness’. I have worked in other logging systems that did that, with the ability to consume the plaintext logs in an ‘old fashioned’ way but a utility being able to do all the nice filtering, search, and special event marking that journalctl provides without compromising the existence of the plain text.
Plain text is slow and cumbersome for large amounts of logs. It would of had a decent performance penalty for little value add.
If you like text you can pipe journalctl
But if journalctl is slow, piping is not helping.
We have only one week of very sparse logs in it, yet it takes several seconds… greping tens of gigabytes of logs can be sometimes faster. That is insane.
Strange
Probably worth asking on a technical
As I said, I’ve dealt with logging where the variable length text was kept as plain text, with external metadata/index as binary. You have best of both worlds here. Plus it’s easier to have very predictable entry alignment, as the messy variable data is kept outside the binary file, and the binary file can have more fixed record sizes. You may have some duplicate data (e.g. the text file has a text version of a timestamp duplicated with the metadata binary timestamp), but overall not too bad.
But why?
I just can’t grasp why such elementary things need to be so fancied up.
It’s not like we don’t have databases and use them for relevant data. But this isn’t it.
And databases with hundreds of milions of rows are faster than journalctl (in my experience on the same hardware).
Just like windows even log
What scared me about it is this kind of shit.
science progresses one funeral at a time
There is nothing scientific about systemd
Do people still debate about systemd?
Neurotypical people do not.
systemd, as a service manager, is decent. Not necessarily a huge improvement for most use cases.
systemd, the feature creep that decides to pull every single possible use case into itself to manage everything in one place, with qwirks because making a “generic, do everything” piece of software is not a good idea, is not that great.
systemd, the group of tools that decided to manage everything by rewriting everything from scratch and suffering from the same issue that were fixed decades ago, just because “we can do better” while changing all well known interfaces and causing a schism with either double workload or dropping support for half the landscape from other software developer is really stupid.
If half the energy that got spent in the “systemd” ecosystem was spent in existing projects and solutions that already addressed these same issues, it’s likely we’d be in a far better place. Alas, it’s a new ecosystem, so we spend a lot of energy getting to the same point we were before. And it’s likely that when we get close to that, something new will show up and start the cycle again.
agree. i find the dns resolver in particular a dumpster fire of shitfuckery. name resolution was shitty, but a solution based on wrapper is just ugh.
same with rust?
Learning how Systemd manages the network was a total mindfuck. There are so many alternatives, all of them being used differently by different tools, partially supported. networkd, Network Manager… There were other tools, they shared similar files but had them in different /etc or /usr folders. There were unexpected interactions between the tools… Oh man, it was so bad. I was very disappointed.
I was really into learning how things really worked in Linux and this was a slap to my face because my mindset was “Linux is so straightforward”. No, it is not, it is actually a mess like most systems. I know this isn’t a “Linux” issue, I’m just ranting about this specific ecosystem.
What’s system md? Sounds like the name of 90s anti-virus software.
Norton McCaffersky System MD Super Scanner Virus Protection.
