10 ms·

Can you provide any specifics of the serious issues you’ve encountered with journald and networkd? There were some performance issues with journald early on, bu

Can you provide any specifics of the serious issues you’ve encountered with journald and networkd? There were some performance issues with journald early on, but I know a lot of work has gone into it over the years (a coworker of mine, for example, improved the performance of log retrieval by 10x). And networkd has always fulfilled my needs nicely, so I’m curious what sort of trouble you ran into.

candiddevmike 2y ago
Only issue I have with networkd is lack of adoption: network manager is pushed hard (Red Hat still clinging to nm for servers, ew) or want to add another abstraction around it (Canonical with netplan). It's an awesome, declarative way to manage networking, embrace it.
- mastax 2y ago
  Yeah I really like networkd as well, switched my Debian servers to it. Netplan also seems fine.
- abcrawf 2y ago
  Man, we fought hard at Red Hat to get them to continue using networkd with their latest container-focused OS. Ultimately, the organization just had too much institutional momentum behind NM. Frankly, I’m disappointed that they lacked the imagination and drive to push the industry forward.
  - 3np 2y ago
    Good on you. I hope they come around. IMO NM has no business on servers and systemd-networkd is relatively robust by now.
Sesse__ 2y ago
journald is still very, very slow. As in, getting the entries for a given process can take a minute or more, whereas just grepping a normal text file is nearly instant. It doesn't help that the default rotation settings are insane (like, why would using a certain percentage of my total space be fine, what if all programs thought that?). Generally I don't really understand what journald brings to the table. I'm sure there are esoteric setups where the hash chaining thing makes sense, but meh? A lot of things needed fixing and systemd fixed many of them, but everything journals is a terrible user experience for me.
- jauntywundrkind 2y ago
  First, i'm a vocal systems appreciater. But. The one thing that frustrates me about the journal is that there is only one journal. If I have a chatty app, it can entirely take over the journal. Set a 1GB hour al, come back in a couple days, and nothing else is left in the journal other than it logging. I hate this so much. If I could assign some apps to a secondary journal, or better quota individual services, that would make sure I can keep tabs on my entire system, even when one app is logging heavily.
  - deleted 2y ago
    [deleted]
  - hackernudes 2y ago
    Check out the LogNamespace option.
    - Brian_K_White 2y ago
      Why? Why must someone check out a new more complicated way to do something that was already simple by default before logs were turned into db rows?
      - jauntywundrkind 2y ago
        Bro no. Logrotate shit was gross and gnarly. Every service has its own way of doing with logs. None of it worked the same. It never was simple it always had been crap. I have my complaints but not replying on each service to do something special conpatible with each other log rotation system was not a complaint. Having this managed reasonably has been great.
- packetlost 2y ago
  This... is just not true. I use journald extensively on a 600Mhz Cortex-A9 daily and it's not slow. I don't know what kind of log load you have, but even when I have processes crashlooping and am sending logs over SSH over a VPN it's fine.
mixmastamyk 2y ago
Tangentially I now have to remove systemd-resolved on each machine. It gets too complicated because I use dnsmasq on family machines and resolved is always trying to open ports to the internet (opensnitch knows). Already run DNS on my router, so why have a second or third cache on each machine? Network manager is involved also.
dmwilcox 2y ago
Networkd is fine if you don't need vlans, bonding, and a bunch of semi-esoteric stuff. /e/n/i does fine there. Journald is too monolithic IMO. Direct access to the files in a text format is standard Unix stuff. Forcing everyone through the journalctl tool is rough, performance being just one issue. The binary format has a habit of changing too, having written a journald log tailer. Overall, like I said, systemd is work software for me. It's fine for the complexity in a company (where you have to balance time and business value), but for my own use I wouldn't choose it. Hence, please don't touch Alpine ;). I was on KISS previously but got tired of compiling my own packages (and Firefox is nigh impossible to compile in a 'ragged' version package system)
- 3np 2y ago
  > Networkd is fine if you don't need vlans, bonding, and a bunch of semi-esoteric stuff. networkd does support vlans, bonding, bridges, and whatnot since quite some time now. https://wiki.archlinux.org/title/VLAN#systemd-networkd https://wiki.archlinux.org/title/VLAN#systemd-networkd https://wiki.archlinux.org/title/Systemd-networkd#Bonding_a_wired_and_wireless_interface https://wiki.archlinux.org/title/Systemd-networkd#Bonding_a_... What more semi-esoteric stuff would you be missing? > Hence, please don't touch Alpine I'm with you here though: I too appreciate Alpine being on OpenRC rather than systemd. And hope a musl port does not change the calculation there. You may also appreciate https://chimera-linux.org/ https://chimera-linux.org/ if you haven't checked it out already.
  - eep_social 2y ago
    I recently found that systemd-networkd isn’t generating “up” events (or something similar, not posting from work) for bonded interfaces set up by cloud init which causes the network wait job to spin until it times out, adding about 60s to boot time for any debian-based box we run in our medium sized deploy, so maybe a few 1000. I noticed because my dev box took forever to come back after a kernel update and I was sweating that I’d broken something. Unfortunately I was unable to allocate the time to figure out systemd at the layer where the event is expected but not generated to file a coherent bug. I ended up working around it several layers up by hard coding “bond0” as an argument in some config and moved on. I don’t think openrc is perfect and I find broken shit in Alpine constantly but when I do it’s a whole lot easier to figure out what broke when you don’t have to dig through several layers of dbus event generators and consumers before figuring out what even happened.

candiddevmike 2y ago

Only issue I have with networkd is lack of adoption: network manager is pushed hard (Red Hat still clinging to nm for servers, ew) or want to add another abstraction around it (Canonical with netplan). It's an awesome, declarative way to manage networking, embrace it.

mastax 2y ago
Yeah I really like networkd as well, switched my Debian servers to it. Netplan also seems fine.
abcrawf 2y ago
Man, we fought hard at Red Hat to get them to continue using networkd with their latest container-focused OS. Ultimately, the organization just had too much institutional momentum behind NM. Frankly, I’m disappointed that they lacked the imagination and drive to push the industry forward.
- 3np 2y ago
  Good on you. I hope they come around. IMO NM has no business on servers and systemd-networkd is relatively robust by now.

Sesse__ 2y ago

journald is still very, very slow. As in, getting the entries for a given process can take a minute or more, whereas just grepping a normal text file is nearly instant. It doesn't help that the default rotation settings are insane (like, why would using a certain percentage of my total space be fine, what if all programs thought that?). Generally I don't really understand what journald brings to the table. I'm sure there are esoteric setups where the hash chaining thing makes sense, but meh? A lot of things needed fixing and systemd fixed many of them, but everything journals is a terrible user experience for me.

jauntywundrkind 2y ago
First, i'm a vocal systems appreciater. But. The one thing that frustrates me about the journal is that there is only one journal. If I have a chatty app, it can entirely take over the journal. Set a 1GB hour al, come back in a couple days, and nothing else is left in the journal other than it logging. I hate this so much. If I could assign some apps to a secondary journal, or better quota individual services, that would make sure I can keep tabs on my entire system, even when one app is logging heavily.
- deleted 2y ago
  [deleted]
- hackernudes 2y ago
  Check out the LogNamespace option.
  - Brian_K_White 2y ago
    Why? Why must someone check out a new more complicated way to do something that was already simple by default before logs were turned into db rows?
    - jauntywundrkind 2y ago
      Bro no. Logrotate shit was gross and gnarly. Every service has its own way of doing with logs. None of it worked the same. It never was simple it always had been crap. I have my complaints but not replying on each service to do something special conpatible with each other log rotation system was not a complaint. Having this managed reasonably has been great.
packetlost 2y ago
This... is just not true. I use journald extensively on a 600Mhz Cortex-A9 daily and it's not slow. I don't know what kind of log load you have, but even when I have processes crashlooping and am sending logs over SSH over a VPN it's fine.

mixmastamyk 2y ago

Tangentially I now have to remove systemd-resolved on each machine. It gets too complicated because I use dnsmasq on family machines and resolved is always trying to open ports to the internet (opensnitch knows). Already run DNS on my router, so why have a second or third cache on each machine? Network manager is involved also.

dmwilcox 2y ago

Networkd is fine if you don't need vlans, bonding, and a bunch of semi-esoteric stuff. /e/n/i does fine there. Journald is too monolithic IMO. Direct access to the files in a text format is standard Unix stuff. Forcing everyone through the journalctl tool is rough, performance being just one issue. The binary format has a habit of changing too, having written a journald log tailer. Overall, like I said, systemd is work software for me. It's fine for the complexity in a company (where you have to balance time and business value), but for my own use I wouldn't choose it. Hence, please don't touch Alpine ;). I was on KISS previously but got tired of compiling my own packages (and Firefox is nigh impossible to compile in a 'ragged' version package system)

3np 2y ago
> Networkd is fine if you don't need vlans, bonding, and a bunch of semi-esoteric stuff. networkd does support vlans, bonding, bridges, and whatnot since quite some time now. https://wiki.archlinux.org/title/VLAN#systemd-networkd https://wiki.archlinux.org/title/VLAN#systemd-networkd https://wiki.archlinux.org/title/Systemd-networkd#Bonding_a_wired_and_wireless_interface https://wiki.archlinux.org/title/Systemd-networkd#Bonding_a_... What more semi-esoteric stuff would you be missing? > Hence, please don't touch Alpine I'm with you here though: I too appreciate Alpine being on OpenRC rather than systemd. And hope a musl port does not change the calculation there. You may also appreciate https://chimera-linux.org/ https://chimera-linux.org/ if you haven't checked it out already.
- eep_social 2y ago
  I recently found that systemd-networkd isn’t generating “up” events (or something similar, not posting from work) for bonded interfaces set up by cloud init which causes the network wait job to spin until it times out, adding about 60s to boot time for any debian-based box we run in our medium sized deploy, so maybe a few 1000. I noticed because my dev box took forever to come back after a kernel update and I was sweating that I’d broken something. Unfortunately I was unable to allocate the time to figure out systemd at the layer where the event is expected but not generated to file a coherent bug. I ended up working around it several layers up by hard coding “bond0” as an argument in some config and moved on. I don’t think openrc is perfect and I find broken shit in Alpine constantly but when I do it’s a whole lot easier to figure out what broke when you don’t have to dig through several layers of dbus event generators and consumers before figuring out what even happened.