3 ms·

I admit, I do not fully understand systemd, but having to add logic like this is very odd. If "too many" is reached, couldn't they add a pause and throw a mess

by jmclnx 1y ago

I admit, I do not fully understand systemd, but having to add logic like this is very odd. If "too many" is reached, couldn't they add a pause and throw a message into /var/log/messages ? This indicates to me a very poor design. If not, it is a validation of the old UNIX saying "do one thing and do it well" and "keep programs small" (paraphrasing).

pengaru 1y ago
> I admit, I do not fully understand systemd ... > This indicates to me a very poor design. If not, it is a validation of the old UNIX saying "do one thing and do it well" and "keep programs small" (paraphrasing). You don't need to fully understand systemd to understand TFA describes a kernel fix. This isn't a systemd problem, systemd just makes use of cgroups. The kernel has a degenerate case handling lazy atime updates combined with cgroups.
- pizlonator 1y ago
  Kinda yeah? I’d say it’s both a systemd issue and a kernel issue. The fact that systemd motivates kernel fixes does point to systemd being maybe just a bit overengineered
  - pengaru 1y ago
    > I’d say it’s both a systemd issue and a kernel issue. The fact that systemd motivates kernel fixes does point to systemd being maybe just a bit overengineered systemd is basically a victim here, you're quasi engaging in a tech form of victim blaming. don't blame systemd for making use of kernel features (cgroups) and without cgroups linux has no sandboxing capabilities, and would be largely irrelevant to today's workloads
    - pizlonator 1y ago
      If I was blaming only systemd then you’d be right. Look if I wrote a thing that caused kernel lockups then I’d blame myself even if the kernel dudes fixed the issue
      - lokar 1y ago
        The kernel has a very clear API and expected behavior. Systemd is not doing anything wrong, it’s using the API correctly. It’s a kernel bug.
- TacticalCoder 1y ago
  [dead]
wrs 1y ago
It’s not really specific to systemd, it’s about cgroups in the kernel. If your code is running as a systemd unit so it gets its own cgroup, there you are.

by jmclnx 1y ago

pengaru 1y ago

> I admit, I do not fully understand systemd ... > This indicates to me a very poor design. If not, it is a validation of the old UNIX saying "do one thing and do it well" and "keep programs small" (paraphrasing). You don't need to fully understand systemd to understand TFA describes a kernel fix. This isn't a systemd problem, systemd just makes use of cgroups. The kernel has a degenerate case handling lazy atime updates combined with cgroups.

pizlonator 1y ago
Kinda yeah? I’d say it’s both a systemd issue and a kernel issue. The fact that systemd motivates kernel fixes does point to systemd being maybe just a bit overengineered
- pengaru 1y ago
  > I’d say it’s both a systemd issue and a kernel issue. The fact that systemd motivates kernel fixes does point to systemd being maybe just a bit overengineered systemd is basically a victim here, you're quasi engaging in a tech form of victim blaming. don't blame systemd for making use of kernel features (cgroups) and without cgroups linux has no sandboxing capabilities, and would be largely irrelevant to today's workloads
  - pizlonator 1y ago
    If I was blaming only systemd then you’d be right. Look if I wrote a thing that caused kernel lockups then I’d blame myself even if the kernel dudes fixed the issue
    - lokar 1y ago
      The kernel has a very clear API and expected behavior. Systemd is not doing anything wrong, it’s using the API correctly. It’s a kernel bug.
TacticalCoder 1y ago
[dead]

wrs 1y ago

It’s not really specific to systemd, it’s about cgroups in the kernel. If your code is running as a systemd unit so it gets its own cgroup, there you are.