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

331–340 of 357 posts

Re: Avoiding Complexity with Systemd

#331

Post by yawaramin »

knorker wrote: post #316
yawaramin wrote: post #266

Earlier quoted context omitted.

> So to me this really looks like it applies neither to servers nor desktop. It applies to both. We need desktops to boot up fast, because you said it yourself, sometimes they just need to. And no one likes waiting around for their machines to boot. Can you imagine the volume of complaints about long boot times that would come in to large-scale distros from annoyed users? That alone makes it a high priority. And on t…

> We need desktops to boot up fast, because you said it yourself, sometimes they just need to I didn't say that. Because they don't. > And no one likes waiting around for their machines to boot. Nobody cares, if it's once for every month or two. Which it is. > we need servers to boot up fast But it's not actually booted until the service is up, so it's moot.

> I didn't say that. Because they don't.

Yes, you did. Here's a refresher:

> My workplace even had to install corp software that forces a reboot every N days (with warnings ahead of time) because people just Do. Not. Reboot.

I.e. sometimes computers just need to reboot, and there's nothing you can do about it.

> Nobody cares

If nobody cares, then why do people hate rebooting so much?

Re: Avoiding Complexity with Systemd

#332

Post by knorker »

zxzax wrote: post #325
knorker wrote: post #317

Earlier quoted context omitted.

> You can just disable the fd passing for services that don't need it. I'm not sure what your actual issue is. First of all this just sounds like "I don't know what your problem with systemd is, you can just choose to not use it". Second, my point is that it's an absolutely terrible idea, and should never have been done. > I believe systemd was inspired by other established unix service managers like macOS launchd an…

If you think the socket activation takes too long you can just turn it off and start that service unconditionally. What's the problem? Other service managers support this too, it's not a systemd only thing. Maybe it's a bad idea for some services but others would seemingly disagree that it's always a terrible idea, and not just those who are systemd developers. You may just be using it for the wrong services -- it's…

> it's most useful with services where the startup time is less important than

So now it's not about startup time at all?

> please consider submitting bug reports and patches to help the project,

Who says I don't?

But systemd needs a few full time adults, not just a patch here and there to fix the launch-while-brainstorming culture that gave us the current situation.

Re: Avoiding Complexity with Systemd

#333

Post by knorker »

zxzax wrote: post #328
knorker wrote: post #320

Earlier quoted context omitted.

> This feature benefits some people. Even if your service requires socket activation, you can still set the service to startup and you can still control it with normal command lines. But it's broken by design. It's a bad idea. It's "neat", but "neat" doesn't add value. > You make this accusation twice, but you give no-one any reason to believe it (unless you think "using an optional feature I don't want to use and wh…

>But it's broken by design. It's a bad idea. You keep saying this, without giving evidence to back it up. People are still running Linux in memory constrained environments, those didn't go away now that the 90s are over. >Using this feature pushes orders of magnitude of complexity onto users, and greatly reduces the ability to error handle or even know the status of services. To be clear, it sounds like what you're s…

> You keep saying this, without giving evidence to back it up

I have, repeatedly. But like in this thread you just reply with the same question asked one more time:

https://news.ycombinator.com/item?id=27653716

> People are still running Linux in memory constrained environments

So why do they have all these memory-hungry services they don't need on standby?

Does that mean that I can DoS these machines simply by connecting to all the open ports, thus starting up the heavy daemons in the constrained environment?

Why is that a good thing?

>> You check if the service is turned on (systemctl or whatever), you check if the process is running (ps, etc), and you check listening ports (netstat, nmap, etc...), they all agree that the service either is or isn't running. And if it's running, it's successfully run its initialization and should be usable.

> This isn't really correct, netstat or nmap won't show process status at all.

This is HN, not reddit, so I'm going to assume you're not just trolling.

    netstat -na | grep tcp.*443
Yes, actually, netstat will show you if you have an HTTPS server running. It will show you if you have an SSH server running.

Same argument with nmap.

Compare this with the fd-passing model, where you can have every port on your system bound, and it tells you nothing (while troubleshooting) which services are actually up.

Do you not see how "all the ports are bound" then becomes completely useless in troubleshooting and checking status?

Will it tell you if you're actually running SSH on port 443? No, of course not. That's not how troubleshooting works, like at all.

Re: Avoiding Complexity with Systemd

#334

Post by knorker »

yawaramin wrote: post #330
knorker wrote: post #315

Earlier quoted context omitted.

You can, but it doesn't. If I know I want to start it I can just connect with the client. Sounds like you're arguing something like "yes, it's broken. But you can just reimplement everything and it won't be broken anymore". Yes, I can also turn off "kill user processes on logout", but that doesn't make that not-broken.

No, I'm arguing there's a way to force-start even socket-activated services. But this is really a moot point. Systemd's socket activation is really meant for system services which would otherwise be in the critical path of system boot. 'Regular' client-facing services that people normally run–webapps, etc.–are not really the target use case. It's fine to start them up in the normal way, with WantedBy=multi-user.targe…

> So you are basically arguing a strawman here.

gpsd is an example that immediately comes to mind that was set to start on-demand. Which is ridiculous.

So it's a straw man that actually exists, making it not a straw man.

Re: Avoiding Complexity with Systemd

#335

Post by knorker »

yawaramin wrote: post #331
knorker wrote: post #316

Earlier quoted context omitted.

> We need desktops to boot up fast, because you said it yourself, sometimes they just need to I didn't say that. Because they don't. > And no one likes waiting around for their machines to boot. Nobody cares, if it's once for every month or two. Which it is. > we need servers to boot up fast But it's not actually booted until the service is up, so it's moot.

> I didn't say that. Because they don't. Yes, you did. Here's a refresher: > My workplace even had to install corp software that forces a reboot every N days (with warnings ahead of time) because people just Do. Not. Reboot. I.e. sometimes computers just need to reboot, and there's nothing you can do about it. > Nobody cares If nobody cares, then why do people hate rebooting so much?

> I.e. sometimes computers just need to reboot, and there's nothing you can do about it.

And this is the attitude that brings us shitty software, and "I dunno, just reboot to fix the problem?", which is what we have now.

Short of kernel upgrades they really really don't.

But if you've bought in to "oh computers just need to reboot sometimes", then I guess you fall into the category of people who have just given up on reliable software, or you don't know that there is an alternative and no this was not normal.

>>> We need desktops to boot up fast, because you said it yourself, sometimes they just need to

>> I didn't say that. Because they don't.

> Yes you did[…] > people just Do. Not. Reboot.

So is that what I said? I believe you did not read what you quoted.

The main reason people reboot is because of shitty software that requires reboots. So if you want to go self-fulfilling prophecy, then systemd is optimizing for boot times because it's low quality software that requires periodic reboots?

But maybe you count forced reboots once a month (or every two months) for kernel upgrades (but also the above arguments since they also run systemd and therefore need reboots). Fine.

So in order to save ten seconds per month (from a boot time of a minute or so, including "bios" and grub wait times, etc.., so not even a large percentage) this fd-passing silently breaks heaps of services, wasting hours here and there? And that's a good idea?

And all for what? Because you chose to have installed services you don't need, and don't use? And if you do use them, then the time was not saved anyway, but just created a second wait-period where you wait for the service to start up?

And ALL of these services could in any case be fully started while you were typing your username and password.

So what use case exactly is being optimized? The computer was idle for maybe half the time between power-on and loaded desktop environment anyway.

> If nobody cares, then why do people hate rebooting so much?

Because all their state is lost. All their open windows, half-finished emails, notepad, window layout, tmux sessions, the running terminal stuff they don't have in tmux sessions, etc… etc…

Re: Avoiding Complexity with Systemd

#336

Post by yawaramin »

knorker wrote: post #335
yawaramin wrote: post #331

Earlier quoted context omitted.

> I didn't say that. Because they don't. Yes, you did. Here's a refresher: > My workplace even had to install corp software that forces a reboot every N days (with warnings ahead of time) because people just Do. Not. Reboot. I.e. sometimes computers just need to reboot, and there's nothing you can do about it. > Nobody cares If nobody cares, then why do people hate rebooting so much?

> I.e. sometimes computers just need to reboot, and there's nothing you can do about it. And this is the attitude that brings us shitty software, and "I dunno, just reboot to fix the problem?", which is what we have now. Short of kernel upgrades they really really don't. But if you've bought in to "oh computers just need to reboot sometimes", then I guess you fall into the category of people who have just given up on…

> And ALL of these services could in any case be fully started while you were typing your username and password.

This is the key point you are refusing to hear. No, all of the services on a modern Linux machine can't be started while you're typing in your credentials. So they're started lazily, on-demand, one of the classic techniques for performance optimization and a hallmark of good engineering.

Re: Avoiding Complexity with Systemd

#337

Post by zh3 »

lathiat wrote: post #306
zh3 wrote: post #246

Earlier quoted context omitted.

Wait until it automagically fails. It may be great for less-skilled people, but for anyone running anything where it's too critical to outsource support it's then necessary to have a systemd expert inhouse (and such a person has proven extremely hard to find).

A support contract from your distro of choice e.g. RedHat, Canonical (Ubuntu), SUSE, etc would potentially fill this void.

OP > "where it's too critical to outsource support"

Re: Avoiding Complexity with Systemd

#338

Post by zh3 »

gmmeyer wrote: post #253
zh3 wrote: post #246

Earlier quoted context omitted.

Wait until it automagically fails. It may be great for less-skilled people, but for anyone running anything where it's too critical to outsource support it's then necessary to have a systemd expert inhouse (and such a person has proven extremely hard to find).

I have never encountered the need for this and I honestly doubt you have either. Systemd fails mysteriously far less often than poorly written init files I have seen and it is honestly not that hard to debug almost every failure I've ever encountered. And I have worked on some very large scale systems with systemd. A systemd file I helped write has run many millions of times over without issue. I honestly find this c…

Ever worked on systems where you're on the hook for the guarantee that you can keep it running?

We had 3 major breakages due to systemd, which is why we went back to something pretty much anyone who knows a bit of bash scripting can fix.

Re: Avoiding Complexity with Systemd

#339

Post by zxzax »

knorker wrote: post #332
zxzax wrote: post #325

Earlier quoted context omitted.

If you think the socket activation takes too long you can just turn it off and start that service unconditionally. What's the problem? Other service managers support this too, it's not a systemd only thing. Maybe it's a bad idea for some services but others would seemingly disagree that it's always a terrible idea, and not just those who are systemd developers. You may just be using it for the wrong services -- it's…

> it's most useful with services where the startup time is less important than So now it's not about startup time at all? > please consider submitting bug reports and patches to help the project, Who says I don't? But systemd needs a few full time adults, not just a patch here and there to fix the launch-while-brainstorming culture that gave us the current situation.

It can also be about initial startup time of the system, not startup time of any individual service. Please follow the site guidelines, c.f. the part about "don't cross-examine" -- this is just a technical tool, I'm sure we both can come up with some ways that it could be useful, even if we wouldn't use them ourselves.

>But systemd needs a few full time adults, not just a patch here and there to fix the launch-while-brainstorming culture that gave us the current situation.

Then start working it on it full time, and get some of your friends hired too? Surely you can find someone to pay for that, if it's useful? What else is it that would satisfy you here? I'd be happy if another group was committing full time to systemd (or another similar open source project) just to fix bugs. I fully support you if you decide to do that.

Re: Avoiding Complexity with Systemd

#340

Post by zxzax »

knorker wrote: post #333
zxzax wrote: post #328

Earlier quoted context omitted.

>But it's broken by design. It's a bad idea. You keep saying this, without giving evidence to back it up. People are still running Linux in memory constrained environments, those didn't go away now that the 90s are over. >Using this feature pushes orders of magnitude of complexity onto users, and greatly reduces the ability to error handle or even know the status of services. To be clear, it sounds like what you're s…

> You keep saying this, without giving evidence to back it up I have, repeatedly. But like in this thread you just reply with the same question asked one more time: https://news.ycombinator.com/item?id=27653716 > People are still running Linux in memory constrained environments So why do they have all these memory-hungry services they don't need on standby? Does that mean that I can DoS these machines simply by conne…

I ask the same question because I haven't yet seen a better alternative that was given. If you have one, please show it, it would be very interesting to me. Otherwise, it sounds like you may not have that much experience with these tools, which is understandable. I can help find solutions, if you're interested.

>Does that mean that I can DoS these machines simply by connecting to all the open ports, thus starting up the heavy daemons in the constrained environment?

I'm not sure I'm understanding this question? A lot of machines are not open to the public internet, so this probably doesn't apply there. You can also use some cgroup managing tool (like systemd) to restrict memory usage to the process and configure the OOM killer behavior, so that would also prevent DoS attacks.

> Yes, actually, netstat will show you if you have an HTTPS server running. It will show you if you have an SSH server running.

Actually no, this is wrong, at least for me when I tried the version of netstat that ships with debian. It only shows if something has the port open -- that thing could be an fd holding service (like inted or systemd or something else), or it could be a load balancer, or it could be another service that is incorrectly configured to use the wrong port, etc. So you're right that this complicates the system but this isn't really systemd's fault, and there is nothing that a service manager can really do about this. The only way to know for sure is to use a different tool that prints information about the owning process -- that way you know for sure if it's sshd or something else. Maybe you have a version of netstat that shows this information? If so, then it's not a problem at all, just simply check that column before you continue with your trouble shooting.

>Will it tell you if you're actually running SSH on port 443? No, of course not.

Well now you got me confused, this seems to be directly conflicting with when you said this: "It will show you if you have an SSH server running"

Post reply on HN