4 ms·

Devuan is basically Debian without systemd. While I still prefer to run Linux distributions with systemd (NixOS and Arch in particular), I'm increasingly worri

by nextos 9y ago

Devuan is basically Debian without systemd. While I still prefer to run Linux distributions with systemd (NixOS and Arch in particular), I'm increasingly worried about the complexity systemd brings in. I like how clean and standardized the init process is now. I don't like the bloat prize we've paid, though. I've been stracing my workstation for a few days. Journald starts eating a ton of RAM, ~100 MB upon boot, and keeps growing. I'm annoyed because systemd developers claim 100 MB is normal. It's not, that's my biggest process on startup. And on my other Arch machine it stays at 25 MB, and they have a long history of memory leaks.

newnewpdro 9y ago
> Journald starts eating a ton of RAM, ~100 MB upon boot, and keeps growing. You must subtract shared from resident to determine how much memory has been "eaten". Journald uses mmap() for random access within the journal files. These pages are accounted for as shared because they are file-backed and may be paged out by the kernel behind the scenes if memory is needed - they'll just be paged back in from the filesystem if accessed later by journald.
craftyguy 9y ago
see newnewpdro's comment. I just built a headless armv7h system (using Arch Linux ARM) with 1GB of RAM, and after being up for 3 days running nginx, ssh, and some other bare services, the total RAM usage, for all applications, is 70-100MB. Systemd is complex, but it really doesn't seem to add a lot of resource drain for the power it give you... I'm happy with that tradeoff.
- tannhaeuser 9y ago
  Out of curiosity, to start nginx and sshd you need like 2 lines of shell code in a BSDish rc.conf - one for starting each service. Why do you think systemd bringing in 10s and 100s of megabytes of black magic binary code is a trade-off worth making, especially on a non-desktop without a need for reacting on up/down events of network interfaces?
  - pmden 9y ago
    Systemd isn't one component, so you'd be mistaken assuming everything in the systemd project is necessary to start a service. But second to that, I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. As for why someone would make that 'trade-off' - I much prefer being able to add "Restart=on-failure" than using daemontools, and I don't have the luxury of working with one single distribution and remember the faff involved with initscripts differing between CentOS and Debian. My reasons aside, I'd think a more sensible question would be "why would you actively avoid using the init system that's shipping by default on what constitutes at least 90% of the Linux server market when you're using Linux?". I don't think eyes equate to quality and stability, but I do think Red Hat, and SUSE, and Canonical and Oracle selling server solutions using it will.
    - dozzie 9y ago
      > I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. My guess: because the "another application" that parses nginx_enable=YES is a (rc) shell script instead of an ELF blob, so you can track its execution.
      - andrewshadura 9y ago
        But do you need to?
        dozzie 9y ago
        Yes, when something goes awry with the initscripts system. And systemd is not exactly famous for its transparency of execution and stability of options' behaviour.
      - JdeBP 8y ago
        That is not actually true. It is of course parsed by a shell, not by a shell script, which is indeed an "ELF blob". Moreover, that shell is, on some operating systems, only one of the parsers. OpenBSD, for example, introduced a rule a few versions ago that rc.conf is not shell script. It is a set of key=value assignments that can be written and read by other programs too, not just by a full shell parser and not requiring a shell script parser. One such program is rcctl. Another is FreeBSD's sysrc.
qplex 9y ago
Systemd is still a mess. I've currently one machine that hangs on reboots because systemd is unable to shut down some service and another that gets its journals corrupted periodically.
andrewshadura 9y ago
> Devuan is basically Debian without systemd. You can already run Debian without systemd today. There's absolutely no need in the fragmentation Devuan creates.
- newnewpdro 8y ago
  I'm under the impression that Devuan's purpose is to actually progress into the future without systemd. I am not under the impression that Debian strives to make progress on the systemd-less use case, it seems more like a minimally supported mode. But it's not something I've investigated, so take that with a big grain of salt.

by nextos 9y ago

newnewpdro 9y ago

> Journald starts eating a ton of RAM, ~100 MB upon boot, and keeps growing. You must subtract shared from resident to determine how much memory has been "eaten". Journald uses mmap() for random access within the journal files. These pages are accounted for as shared because they are file-backed and may be paged out by the kernel behind the scenes if memory is needed - they'll just be paged back in from the filesystem if accessed later by journald.

craftyguy 9y ago

see newnewpdro's comment. I just built a headless armv7h system (using Arch Linux ARM) with 1GB of RAM, and after being up for 3 days running nginx, ssh, and some other bare services, the total RAM usage, for all applications, is 70-100MB. Systemd is complex, but it really doesn't seem to add a lot of resource drain for the power it give you... I'm happy with that tradeoff.

tannhaeuser 9y ago
Out of curiosity, to start nginx and sshd you need like 2 lines of shell code in a BSDish rc.conf - one for starting each service. Why do you think systemd bringing in 10s and 100s of megabytes of black magic binary code is a trade-off worth making, especially on a non-desktop without a need for reacting on up/down events of network interfaces?
- pmden 9y ago
  Systemd isn't one component, so you'd be mistaken assuming everything in the systemd project is necessary to start a service. But second to that, I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. As for why someone would make that 'trade-off' - I much prefer being able to add "Restart=on-failure" than using daemontools, and I don't have the luxury of working with one single distribution and remember the faff involved with initscripts differing between CentOS and Debian. My reasons aside, I'd think a more sensible question would be "why would you actively avoid using the init system that's shipping by default on what constitutes at least 90% of the Linux server market when you're using Linux?". I don't think eyes equate to quality and stability, but I do think Red Hat, and SUSE, and Canonical and Oracle selling server solutions using it will.
  - dozzie 9y ago
    > I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. My guess: because the "another application" that parses nginx_enable=YES is a (rc) shell script instead of an ELF blob, so you can track its execution.
    - andrewshadura 9y ago
      But do you need to?
      - dozzie 9y ago
        Yes, when something goes awry with the initscripts system. And systemd is not exactly famous for its transparency of execution and stability of options' behaviour.
    - JdeBP 8y ago
      That is not actually true. It is of course parsed by a shell, not by a shell script, which is indeed an "ELF blob". Moreover, that shell is, on some operating systems, only one of the parsers. OpenBSD, for example, introduced a rule a few versions ago that rc.conf is not shell script. It is a set of key=value assignments that can be written and read by other programs too, not just by a full shell parser and not requiring a shell script parser. One such program is rcctl. Another is FreeBSD's sysrc.

qplex 9y ago

Systemd is still a mess. I've currently one machine that hangs on reboots because systemd is unable to shut down some service and another that gets its journals corrupted periodically.

andrewshadura 9y ago

> Devuan is basically Debian without systemd. You can already run Debian without systemd today. There's absolutely no need in the fragmentation Devuan creates.

newnewpdro 8y ago
I'm under the impression that Devuan's purpose is to actually progress into the future without systemd. I am not under the impression that Debian strives to make progress on the systemd-less use case, it seems more like a minimally supported mode. But it's not something I've investigated, so take that with a big grain of salt.