Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd 252

github.com

Post reply on HN
Print view View original

41–50 of 317 posts

Re: Systemd 252

#41

Post by okasaki »

boncho wrote: post #2

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.

I had to chattr +i /etc/resolv.conf because my resolv.conf would keep getting truncated (as in empty) every time I restarted an lxd container. Rock solid my ass.

Re: Systemd 252

#42

Post by plaguepilled »

erik_seaberg wrote: post #40
plaguepilled wrote: post #6

Earlier quoted context omitted.

I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions…

nohup is POSIX, systemd is decidedly not. That makes it systemd’s responsibility not to break nohup, and more generally not to require non-admin users to be aware of it.

Not sure I fully understand this argument. Can you expand? I'm not familiar with nohup and its role.

Re: Systemd 252

#43

Post by plaguepilled »

panick21_ wrote: post #33
plaguepilled wrote: post #6

Earlier quoted context omitted.

I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions…

You can easily have it not produce binary logs. Other software depending on Systemd isn't really Systemd responsibility. Its not systemd fault that almost nobody uses OpenRC.

I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important.

Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.

Re: Systemd 252

#44

Post by [deleted] »

shrubble wrote: post #13

People who want to use it can use it. I am thankful for the non-systemd distributions, which are listed at https://nosystemd.org ; just scroll down to the list if you want to skip the advocacy.

[deleted]

Re: Systemd 252

#45

Post by Timja »

I despise systemd.

Having shell scripts that you can read and edit makes so much more sense.

Putting a script in a directory to have it run at startup makes sense. Systemd's approach of "registering a service" is hell.

Having logs in plain text is beautiful. Having to use special software to read logs is hell.

Re: Systemd 252

#46

Post by gupnop »

plaguepilled wrote: post #43
panick21_ wrote: post #33

Earlier quoted context omitted.

You can easily have it not produce binary logs. Other software depending on Systemd isn't really Systemd responsibility. Its not systemd fault that almost nobody uses OpenRC.

I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important. Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.

There are solid technical reasons for systemd's binary logging.

The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones.

Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can help guard against log tampering.

Re: Systemd 252

#48

Post by erik_seaberg »

plaguepilled wrote: post #42
erik_seaberg wrote: post #40

Earlier quoted context omitted.

nohup is POSIX, systemd is decidedly not. That makes it systemd’s responsibility not to break nohup, and more generally not to require non-admin users to be aware of it.

Not sure I fully understand this argument. Can you expand? I'm not familiar with nohup and its role.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/n... blocks SIGHUP and captures output in a file. That lets me type

  nohup ./long_batch_job.sh &
and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost.

systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end users shouldn’t need to talk to init.

Re: Systemd 252

#49

Post by conradev »

boncho wrote: post #2

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.

From an outsider perspective these stick out to me as most important:

- Unified logging subsystem

- On-demand launching, memory limits, and general resource management

- Advanced security features, i.e. sandboxing, DynamicUser

- Well thought out and implemented given the constraints (feels like Linux quality)

In general it represents a shifting of code from daemon developers (who previously handled daemonization themselves) to the system.

On-demand launching is good for performance: work can be deferred from boot and inactive daemons can be stopped. This is critical on battery and RAM constrained devices

Re: Systemd 252

#50

Post by Octabrain »

Timja wrote: post #45

I despise systemd. Having shell scripts that you can read and edit makes so much more sense. Putting a script in a directory to have it run at startup makes sense. Systemd's approach of "registering a service" is hell. Having logs in plain text is beautiful. Having to use special software to read logs is hell.

You can still have your wonderful script but in the case of systemd, you delegate the execution lifecycle of that script to a unit, which, IMHO, is a great abstraction compared to the mess of having to deal with the status of the service from the script itself. You simply throw the unit file into directory, then enable it. Your script does its thing, systemd deals with when to run it, in which runlevel etc

About the logs, yes, plain text files, commands and pipes are great, but journalctl is really great too. It is powefull and includes everything you might need to inspect logs with accuracy in the same tool.

Just to clarify: I'm not a fanboy, I'm just pragmatic.

Post reply on HN