5 ms·

Do you have an example of when systemd is not used for good?

egberts1 4y ago
it kills production daemons having long running stateful data whenever the netdev goes offline., systemd-networkd, that is.
- viraptor 4y ago
  Only if you configure it to do that. You can use Wants= and After= for your service to start it after the network, but not restart otherwise. The behaviour you describe is not unreasonable to want: If your network device goes away, what exactly are you binding the socket to? How are you restoring the listening when it comes back up? But it's up to you to say which one you want.
  - egberts1 4y ago
    Its never a good systemd-networkd default to be killing daemon whenever a netdev goes “cricket”.
    - viraptor 4y ago
      It's not a networkd default. Networkd doesn't kill or even care about other services. The setting exists on the service's unit side. You have to explicitly specify how you want to depend on networking.
      - egberts1 4y ago
        Try it. Pull the Ethernet cable.
        viraptor 4y ago
        I do that every day moving between WiFi and plugged in Ethernet. It seems you're misunderstanding what exactly is killing processes in your case. Try to collect the logs and maybe ask on serverfault. I promise networkd is not killing your processes and if you don't have strict dependencies in your unit file, systemd is unlikely to do that either.
        egberts1 4y ago
        it is a good thing you have no states to care for.
        crazy_hombre 4y ago
        An ethernet interface is not a netdev. Netdevs are always virtual interfaces.
houzi 4y ago
It's quite annoying to not be able to use common tools for DNS queries like `dig`, when using `systemd-resolved` for DNS. I think you might have to sometimes flush the caching feature of `systemd-resolved` as well. It's fine, I guess. But it did take a while to learn the new ways. I think this is the main complaint from users with decades of experience. Their scripts and old knowledge stops working.

it kills production daemons having long running stateful data whenever the netdev goes offline., systemd-networkd, that is.

viraptor 4y ago
Only if you configure it to do that. You can use Wants= and After= for your service to start it after the network, but not restart otherwise. The behaviour you describe is not unreasonable to want: If your network device goes away, what exactly are you binding the socket to? How are you restoring the listening when it comes back up? But it's up to you to say which one you want.
- egberts1 4y ago
  Its never a good systemd-networkd default to be killing daemon whenever a netdev goes “cricket”.
  - viraptor 4y ago
    It's not a networkd default. Networkd doesn't kill or even care about other services. The setting exists on the service's unit side. You have to explicitly specify how you want to depend on networking.
    - egberts1 4y ago
      Try it. Pull the Ethernet cable.
      - viraptor 4y ago
        I do that every day moving between WiFi and plugged in Ethernet. It seems you're misunderstanding what exactly is killing processes in your case. Try to collect the logs and maybe ask on serverfault. I promise networkd is not killing your processes and if you don't have strict dependencies in your unit file, systemd is unlikely to do that either.
      - egberts1 4y ago
        it is a good thing you have no states to care for.
      - crazy_hombre 4y ago
        An ethernet interface is not a netdev. Netdevs are always virtual interfaces.

houzi 4y ago

It's quite annoying to not be able to use common tools for DNS queries like `dig`, when using `systemd-resolved` for DNS. I think you might have to sometimes flush the caching feature of `systemd-resolved` as well. It's fine, I guess. But it did take a while to learn the new ways. I think this is the main complaint from users with decades of experience. Their scripts and old knowledge stops working.