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

61–70 of 317 posts

Re: Systemd 252

#61

Post by Denvercoder9 »

cat_plus_plus wrote: post #31

Is the project a new site sponsor or something? :-) I get it that systemd has some benefits - faster startup, more reliable production administration. And at the same time it's not everyone's cup of tea - for example, many believe that the strength of UNIX is many simple and interchangable commands rather than big monolithic code base controlled by a single team. Anyway, there have been 251 previous versions of syste…

> Anyway, there have been 251 previous versions of systemd

Trivia: when udev (which was at v182) was merged into the systemd project, they skipped from v44 to v183 to align the version numbers; so there have only been 112 previous versions of systemd.

Re: Systemd 252

#62

Post by kaba0 »

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.

Nohup is a disgusting hack from a previous century. I don’t see how having less information on what is happening to a process good — nohup interprets supposedly meaningful signals never meant for this misuse differently.

If you want to continue to run a process you have to start a service which is exactly that.

Re: Systemd 252

#63

Post by awruko »

gupnop wrote: post #46
plaguepilled wrote: post #43

Earlier quoted context omitted.

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…

> indexed for quicker searching and filtering

I think I am not the only one who is missing negative filters - check the log excluding audit messages.

Re: Systemd 252

#64

Post by kaba0 »

erik_seaberg wrote: post #60
teddyh wrote: post #52

Earlier quoted context omitted.

Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup comm…

I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?

How is systemd not under the user’s control? It is an init and service management system and long-running processes are services. Where else should it be managed? Systemd is the only component that knows whether you are logged in/out, whether you still have another seat open, etc. And its responsibility is to properly close resources, and not let unannounced processes to linger needlessly in the background.

Re: Systemd 252

#65

Post by gorgoiler »

It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend.

How long until “Systemd: The Good Parts”?

*The most trivial new name would be système which would at least be in keeping with the French naming.

**In Debian stable if you create a new user, ssh in as that user, logout, then delete the user, you can’t because systemd is still running a detached housekeeping process as that user. If you wait a bit then the systemd process goes away but that, to me, makes it a worse bug not a better one.

Re: Systemd 252

#66

Post by xdfgh1112 »

oblio wrote: post #19
xdfgh1112 wrote: post #14

Earlier quoted context omitted.

Hey, someone rediscovered xinetd

> Hey, someone rediscovered xinetd 1. http://0pointer.de/blog/projects/systemd.html Replacing inetd was a systemd design goal. 2. Snark for someone learning is a bad move.

It was in jest, xinetd is clearly not as powerful as systemd and I'm glad to be rid of it.

Re: Systemd 252

#67

Post by xdfgh1112 »

KingOfCoders wrote: post #30
xdfgh1112 wrote: post #14

Earlier quoted context omitted.

Hey, someone rediscovered xinetd

Isn't it astonishing? I've been using Linux pre-Slackware with downloading boot.tgz and root.tgz on two floppy drives, wrestled with M4 and sendmail, have been writing internet applications for 35+ years but never used a Linux daemon to manage my applications. You're never too old to learn I guess.

I use systemd at work and I have finally learned to love it. Still don't like binary logs but the timers, watchdog and sandboxing features are wonderful.

Re: Systemd 252

#68

Post by teddyh »

erik_seaberg wrote: post #60
teddyh wrote: post #52

Earlier quoted context omitted.

Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup comm…

I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?

systemd-logind(1) manages user sessions. If you want to replicate the functionality of what “nohup” used to give you, I am reliably informed that “systemd-run --scope --user $command” does the right thing. Or, you can enable it permanently for your user with “loginctl enable-linger”.

Re: Systemd 252

#69

Post by xdfgh1112 »

erik_seaberg wrote: post #48
plaguepilled wrote: post #42

Earlier quoted context omitted.

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 use…

They broke tmux too:

https://superuser.com/questions/1372963/how-do-i-keep-system...

Systemd does a lot of good but they like to move fast and break things. Making tmpdir per process, their homedir changes etc are all good for security but tend to break things in unexpected ways

Re: Systemd 252

#70

Post by xdfgh1112 »

otabdeveloper4 wrote: post #35
stopdropnhotpot wrote: post #22

systemd is fine for single user systems and perhaps verts, but I would never deploy it on a server. The deprecation of cgroup v1 is a welcome change. It's come a long way, but it still has a very long way to go.

Quoted post unavailable.

That isn't so true anymore, given their focus on home directory management and killing all user processes on logout (desktop-focused and doesn't work well with tmux or ssh)
Post reply on HN