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

Avoiding Complexity with Systemd

mgdm.net

Post reply on HN
Print view View original

221–230 of 357 posts

Re: Avoiding Complexity with Systemd

#221

Post by bkor »

josephcsible wrote: post #142
5e92cb50239222b wrote: post #128

Earlier quoted context omitted.

A thoughtful comment downvoted into oblivion without any explanation. Classic HN. I too don't get the hate that binary logs receive. They aren't any harder to work with than text logs. journalctl makes it easy to read logs from an offline system, too. The compression it automatically provides saves a lot of space across our machines. I know that it can be achieved without binary logs, but does any popular distributio…

> I know that it can be achieved without binary logs, but does any popular distribution implement compression out of the box? Are you saying that since distros don't optimally configure a program out of the box, we should scrap and replace the whole program instead of just fixing its default configuration?

> we should scrap and replace the whole program instead of just fixing its default configuration?

Loads of distributions assisted that upstream works out of the box with systemd. That way the work is shared across distributions. Not sure why you make such a strange suggestion. Loads of work has been saved thanks to systemd. So much more is shared across distributions it's kind of crazy to look back.

Re: Avoiding Complexity with Systemd

#222

Post by e12e »

kaba0 wrote: post #154
iso1210 wrote: post #118

Earlier quoted context omitted.

Ouch, what on earth does "log out" even mean? What a terrible way to run any computer other than maybe a single user laptop.

Not sure if sarcastic, but the systemd default makes sense. Why should random processes linger in a background, with an ill defined “not answering a signal” hack? There is no distinction between a frozen process and tmux. They can easily register a user service and continue running there.

> They can easily register a user service and continue running there.

Typically this was an issue on B) workstations, and B) servers, where you might log in as a regular user without super user access.

And this[1] (might?) now work as advertised in the documentation - but the discussion around the bug doesn't induce great confidence...

https://github.com/systemd/systemd/issues/3388

[1] example no 5 here: https://www.man7.org/linux/man-pages/man1/systemd-run.1.html...

Re: Avoiding Complexity with Systemd

#223

Post by AtlasBarfed »

birdyrooster wrote: post #62
smitty1e wrote: post #30

Earlier quoted context omitted.

Systemd seems to do a good job of moving the complexity of managing the privileged/unprivileged divide into a standardized service. I sympathize with the "transition sucks" sentiments elsewhere on this post. Having a bunch of working scripts turned into instant technical debt cannot be pleasant. But, as with python3, systemd seems to be the way things are headed.

Why are we talking like this? We’ve been using systemd for over 5 years. It’s weird. Time loops.

I don't have a horse in the systemd vs init.d, I'm a dumb groovy programmer after all.

But you are right, adoption is not enthusiastic, which to me is a massive indictment of the design and usability. We'll basically spin wheels until someone gets annoyed with it and does systemd better, or at least more modularized.

My complaint? sudo systemctl means the verb cannot be autocompleted or introspected like sudo service could be. May be minor, but it's generally my only interaction with systemd versus init.d, and to me they completely blew the only thing I use. Not a good impression.

I understand that init.d was a cobbled set of scripts, loose conventions, and even some hacks. But the resistance to system.d is so pervasive it cannot just be stubborn unix neckbeards.

Re: Avoiding Complexity with Systemd

#224

Post by lanstin »

ketzu wrote: post #176
teknopaul wrote: post #158

Trying to avoid complexity by being dependent on something horribly complex is not going to work.

> Trying to avoid complexity by being dependent on something horribly complex is not going to work. It is probably unavoidable, looking at how complex modern compilers, processors and kernels are. They sure do make a lot of things simpler, though.

Yeah if it is simple to use and has all the hooks I might want eventually, I don’t mind a complex implementation. Better one complex but popular implementation behind simple config than a bunch of people DIYing it. As long as turning on some high detail debug/tracing is possible so I can debug the complexity if needed

Re: Avoiding Complexity with Systemd

#225

Post by lanstin »

spinax wrote: post #200
lanstin wrote: post #194

Earlier quoted context omitted.

I generally love it but had some weird bug a month or two ago where something in the distro (AWS Linux 2) added a log trimmer config for squid that made systemd restart the squids, not reload but restart, every thirty minutes, on all the hosts, so all the clients got connection reset every thirty minutes. The signals to restart came from PID 1 but the fix was commenting out the log trimmer config for squid. Hard to d…

> added a log trimmer config for squid I feel your pain - I'm curious, was it a drop-in /etc/logrotate.d/ config which was sending a HUP? I don't run squid but Google'd up that it will take a USR1 to rotate logs which should not close the HTTP connections (allegedly HUP closes them). Perhaps the AL2 folks chose the wrong signal? https://wiki.squid-cache.org/SquidFaq/InstallingSquid#squid_...

Root causing it is on my todo. For now I just commented the config in my user-data.sh

Re: Avoiding Complexity with Systemd

#226

Post by lanstin »

spinax wrote: post #200
lanstin wrote: post #194

Earlier quoted context omitted.

I generally love it but had some weird bug a month or two ago where something in the distro (AWS Linux 2) added a log trimmer config for squid that made systemd restart the squids, not reload but restart, every thirty minutes, on all the hosts, so all the clients got connection reset every thirty minutes. The signals to restart came from PID 1 but the fix was commenting out the log trimmer config for squid. Hard to d…

> added a log trimmer config for squid I feel your pain - I'm curious, was it a drop-in /etc/logrotate.d/ config which was sending a HUP? I don't run squid but Google'd up that it will take a USR1 to rotate logs which should not close the HTTP connections (allegedly HUP closes them). Perhaps the AL2 folks chose the wrong signal? https://wiki.squid-cache.org/SquidFaq/InstallingSquid#squid_...

But systemd itself was setting the squid service into stop then start. I don’t think by that time systemd knew the reason was to do with logs.

Re: Avoiding Complexity with Systemd

#227

Post by throw-8462682 »

knorker wrote: post #163
j16sdiz wrote: post #93

Earlier quoted context omitted.

Not OP. I my experience, systemd config is simple because it handles all the complexity. Inside it’s guts, it is much more complicated than a sysv system — naturally so because it can do so much more. Those folks loves using the latest and greatest kernel function for all its glory. All works well - until it don’t. When something is broken, suddenly you have to understand all the interdependent components to debug. B…

Agree with that. It breaks catastrophically. But it's also overengineered. Like starting a daemon on first connect is "neat trick", but should never have gone beyond that. Like: oh, I want to restart this daemon, because I want it to re-run its init code (possibly with new settings), but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart"…

Starting a daemon on first connect is essential for fast boot times of a system with multiple dependent network services. This is mostly a desktop use case though. Not sure if it can be disabled for servers.

Re: Avoiding Complexity with Systemd

#228

Post by e12e »

forgotpwd16 wrote: post #185
GuidoW wrote: post #179

Earlier quoted context omitted.

Agreed. One point is that processes other than root cannot start services on ports However, with single-serving services (e.g. in vm/container/vps/cloud), there is no need for it. BSD lets you configure it with a sysctl option. But Linux defends that option like it is still 1990. On NixOS, I patch it like this: boot.kernelPatches = [ { name = "no-reserved-ports"; patch = path/to/no-reserved-ports.patch; } ]; With the…

Does it really change anything running something on port 90 rather port 1090?

If you get unprpivileged access to a system, and somehow manage to crash sshd, or win a race to bind port 22 when sshd restarts, you can intercept other logins.

If you can bind port 80,you can gets ssl certs via let's encrypt (which could let you intercept not just web, but also smtp/imap etc).

So yes, it can make a difference. Of course - it's better if the user doesn't have access to begin with.

This might be more interesting for classical multi-user servers than "single use" servers that don't allow "regular" users to login via ssh.

Re: Avoiding Complexity with Systemd

#229

Post by ggregoire »

Nextgrid wrote: post #204
stefanha wrote: post #48

Recently I have been wondering if systemd solves problems that are becoming less and less relevant to developers. New services are often deployed as containers. While systemd has a bunch of container-related functionality, it does not integrate well into the Kubernetes or even Docker workflow. It's used very little in those environments. If you are building CoreOS or NixOS system images, or traditional Linux system s…

Containers might be popular in startups' "pay five figures a month to $CLOUD_PROVIDER" scene when VCs rain infinite free money, but there are still plenty of occurrences where you have to deal with old-school physical machines where it's often easier to just run the software on the bare-metal rather than using Docker and yet another layer of abstraction.

I run a bunch of services written in python on 50+ bare metals and I can tell you it made my life easier to dockerize everything.

Re: Avoiding Complexity with Systemd

#230

Post by diragon »

stefanha wrote: post #48

Recently I have been wondering if systemd solves problems that are becoming less and less relevant to developers. New services are often deployed as containers. While systemd has a bunch of container-related functionality, it does not integrate well into the Kubernetes or even Docker workflow. It's used very little in those environments. If you are building CoreOS or NixOS system images, or traditional Linux system s…

Nomad has a systemd-nspawn driver in the community section, though. https://www.nomadproject.io/docs/drivers/external/nspawn
Post reply on HN