3 ms·

> boot: you can not only control boot but never boot into the network reliably, because under systemd you have no control over the sequence. BTW, I think that

> boot: you can not only control boot but never boot into the network reliably, because under systemd you have no control over the sequence. BTW, I think that's one of the main pros and one of the strongest features of systemd, but it is also what makes it unreliable and boot unreproducible if you live outside of the very default Ubuntu instance and such.

jraph 1y ago
> never boot into the network reliably What does this mean? Your machine boots and sometimes doesn't have network? If your boot is unreliable, isn't it because some service you try to boot has a dependency that's not declared in its unit file?
- egorfine 1y ago
  > Your machine boots and sometimes doesn't have network? Sometimes it waits on the network to be available with network being available. No idea what causes this. > some service you try to boot has a dependency that's not declared in its unit file Nah, that would be an obvious and easy fix.
  - jraph 1y ago
    Haven't noticed this. This looks like a bug more than a fundamental issue.
    - egorfine 1y ago
      My feeling is that this is not exactly a bug but rather an obscure side effect of systemd being non-transparent.
      - ongy 1y ago
        The default hook systemd uses to wait for network is documented in https://www.freedesktop.org/software/systemd/man/latest/systemd-networkd-wait-online.service.html https://www.freedesktop.org/software/systemd/man/latest/syst... It has the slightly odd behavior with trying to get all configured links up. This can lead to some unexpected behavior when there's more than one. But yea, the upstream stance is essentially "don't rely on network to be up before you start. That's bad software. You have to deal with network going down and back up in practice either way." Which is often not super useful.
        egorfine 1y ago
        > is documented in Yeah, did not help. > trying to get all configured links up Extremely helpful when some are explicitly disabled. So maybe there is a bit of a bug there, who knows. > don't rely on network to be up before you start Yeah that's the correct way.
godelski 1y ago
Are you talking about `NetworkManager.service`? It has a 600s timeout. You can reduce that if you want it to fail faster. But that doesn't seem like a problem with systemd, that seems like a problem with your network connection. > If you live outside of the very default Ubuntu instance and such. I use Arch btw
- egorfine 1y ago
  I'm not sure which of the turds (NetworkManager, netplan) are currently installed with ubuntu and what's their relationship with systemd but I equally hate them all. My ubuntu initiation script includes apt-get install ifupdown, which actually works unlike those two. And why bother learning because by the next ubuntu release the upcoming fanboys will replace the network stack by whatever they think they like - again. But the bug we are discussing is probably systemd's, because the network is up and running while systemd still waits for it.

jraph 1y ago

> never boot into the network reliably What does this mean? Your machine boots and sometimes doesn't have network? If your boot is unreliable, isn't it because some service you try to boot has a dependency that's not declared in its unit file?

egorfine 1y ago
> Your machine boots and sometimes doesn't have network? Sometimes it waits on the network to be available with network being available. No idea what causes this. > some service you try to boot has a dependency that's not declared in its unit file Nah, that would be an obvious and easy fix.
- jraph 1y ago
  Haven't noticed this. This looks like a bug more than a fundamental issue.
  - egorfine 1y ago
    My feeling is that this is not exactly a bug but rather an obscure side effect of systemd being non-transparent.
    - ongy 1y ago
      The default hook systemd uses to wait for network is documented in https://www.freedesktop.org/software/systemd/man/latest/systemd-networkd-wait-online.service.html https://www.freedesktop.org/software/systemd/man/latest/syst... It has the slightly odd behavior with trying to get all configured links up. This can lead to some unexpected behavior when there's more than one. But yea, the upstream stance is essentially "don't rely on network to be up before you start. That's bad software. You have to deal with network going down and back up in practice either way." Which is often not super useful.
      - egorfine 1y ago
        > is documented in Yeah, did not help. > trying to get all configured links up Extremely helpful when some are explicitly disabled. So maybe there is a bit of a bug there, who knows. > don't rely on network to be up before you start Yeah that's the correct way.

godelski 1y ago

Are you talking about `NetworkManager.service`? It has a 600s timeout. You can reduce that if you want it to fail faster. But that doesn't seem like a problem with systemd, that seems like a problem with your network connection. > If you live outside of the very default Ubuntu instance and such. I use Arch btw

egorfine 1y ago
I'm not sure which of the turds (NetworkManager, netplan) are currently installed with ubuntu and what's their relationship with systemd but I equally hate them all. My ubuntu initiation script includes apt-get install ifupdown, which actually works unlike those two. And why bother learning because by the next ubuntu release the upcoming fanboys will replace the network stack by whatever they think they like - again. But the bug we are discussing is probably systemd's, because the network is up and running while systemd still waits for it.