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

351–357 of 357 posts

Re: Avoiding Complexity with Systemd

#351

Post by Arnavion »

nh2 wrote: post #329
Arnavion wrote: post #285

Earlier quoted context omitted.

What does systemd.services.nginx.unitConfig.StartLimitIntervalSec = 0; do that it doesn't require root? If the point is that it's not manipulating a system-level nginx service but a user-level one, then writing the systemd override file in the way I described doesn't require root either.

Applying the NixOS config requires root -- that's not what it's about. What I mean is that services can set other services' options, without you (the admin) having to to write such overrides manually.

Nothing prevents $service's package from creating /etc/systemd/system/nginx.service.d/90-restart-always.conf in a regular distro.

Re: Avoiding Complexity with Systemd

#352

Post by LargoLasskhyfv »

SiberianDweller wrote: post #342
InvertedRhodium wrote: post #303

Earlier quoted context omitted.

The scenario I personally have is: - Legacy application, with no access to source code. - Company that wrote the application hasn't existed for a decade. - It logs several useless lines every second. This is non-configurable, and includes a timestamp which makes each linue distinct. - It also logs some very important lines that _must_ be responded to. I don't think this is a unique situation to find yourself in, and…

How about to open this exceedly verbose legacy program with IDA and fill with NOPs all the places where this program logs something useless? I mean, this is an activity which really should be named as "hacking", in opposition to playing with init scripts.

Or maybe discovering configurability of log/debug levels via environment variables.

Re: Avoiding Complexity with Systemd

#353

Post by lanstin »

WesolyKubeczek wrote: post #276
lanstin wrote: post #226

Earlier quoted context omitted.

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.

I'm wondering if this new config made squid exceed any limits, causing it to hard stop. I'd expect the log trimmer to have/cause a bug in squid itself.

It was sharply at :00 and :30 so I think it was time based and not reality based.

Re: Avoiding Complexity with Systemd

#354

Post by lanstin »

mananaysiempre wrote: post #313
lanstin wrote: post #231

Earlier quoted context omitted.

I stopped reading when they started attacking bind. Sheer ignorance. Also cathedral is good for him and his elite team but not in general? Unix has always been worse is better. You may disagree but it is the secret sauce. YAGNI for that potentially ideal system. Sadly. I like mathematically solid systems but the people with good enough systems explore the solution space much quicker.

I’m not sure what you are referring to. Do you mean some other page on that website? There’s a fair bit of design philosophy there, and I vaguely remember reading it and agreeing with some parts while disagreeing with others, but that was years ago. I’ve no interest in defending an arbitrarily chosen subset of the author’s views in this thread. Indeed I don’t even necessarily agree with everything said on the page I…

> Software that does more instead of less is, simply put, badly designed software. Trying to come up with an all-encompassing solution is always a sign of developer hubris and inexperience, and never a sign of good engineering. Ever. Remember sendmail, BIND, INN,

Yeah from the skarnet page above. BIND had many troubles over the years but mostly because we were all learning about secure code practices in C etc. bind was just a name server. Never heard of it reading mail. There was a lot to learn about network exploits, for sure. But attacking bind as doing too much seems disingeneous. And the whole tone reminds me of the same tone as https://suckless.org/ who cares if some browser takes a Gig of RAM or my window manager is ginormous. My laptop is hard pressed to use all the RAM it has and if systemd and the kernel is running sixty daemons but the unit files are easy to write as a here doc in cloud init, then win win win.

(Running postfix and bind on my personal cloud VMs; have run Apache, haproxy, nginx and lighttpd, as well as built in Python web servers).

Re: Avoiding Complexity with Systemd

#355

Post by mrlonglong »

josephcsible wrote: post #127
tyingq wrote: post #44

My frustration with systemd is that it creeps out over time into other functionality, and that it's difficult to find the right documentation. Like when logind was changed to kill background processes when you log out, by making KillUserProcesses=yes the default. Some Linux distros left that as is, others overrode it in /etc/systemd/logind.conf. So, figuring out what was happening, and how to fix it, was confusing. I…

In particular, "background processes" includes screen/tmux sessions that you started. This change completely broke the largest reason that people use screen or tmux.

That was a time when I was sorely tempted to dump a huge load of manure all over Lennart Poettering.

Re: Avoiding Complexity with Systemd

#356

Post by WesolyKubeczek »

InvertedRhodium wrote: post #303
WesolyKubeczek wrote: post #289

Earlier quoted context omitted.

Isn't this something that, to a degree, might be mitigated by rate limiting journald has? IMO Lennart is right in that collection should be optimized to a point where it is (almost) never the bottleneck. I, personally, would put a filtering program between the chatty application and journald.

The scenario I personally have is: - Legacy application, with no access to source code. - Company that wrote the application hasn't existed for a decade. - It logs several useless lines every second. This is non-configurable, and includes a timestamp which makes each linue distinct. - It also logs some very important lines that _must_ be responded to. I don't think this is a unique situation to find yourself in, and…

What you need is a pipe through grep. It’s as reliable as it gets. I don’t understand, though, why your log filter should all of a sudden grow disk space monitoring and signal handling. This is what systemd and journald should be doing, and in their recent versions, they are quite capable.

Re: Avoiding Complexity with Systemd

#357

Post by throw-8462682 »

knorker wrote: post #321
throw-8462682 wrote: post #319

Earlier quoted context omitted.

> But it's not actually booted until the service is up, so it's moot. With per second billing, fast boot times save money and enable lower fixed capacity, further lowering cost.

But no it doesn't. Until your service is started, your service is NOT actually booted. That's what I said. You are not paying per-second for the VM. The VM itself adds zero value to you. It's the service that's running (or in this case, not) that you're paying for. Who cares how long it takes before systemd calls listen()? Nobody derives value from that. You're not paying for that. You're paying for the SERVICE to be…

Starting services in parallel will reduce overall service start up time as well, even if services are dependent on each other, because services often do work before they connect to a dependent service. Without socket activation that is a race condition.
Post reply on HN