6 ms·

> If you need to reboot the server right now for some reason, will that service come back up on reboot? I didn’t see this discussed more after it was asked, bu

by memco 5y ago

> If you need to reboot the server right now for some reason, will that service come back up on reboot? I didn’t see this discussed more after it was asked, but I could use some pointers on how to answer this question since I have a service I wrote that I think should start on reboot, but has to be started manually. It would be nice to know when I have fixed it without having to reboot after each change to just to test. Anyone know how I can do that?

rav 5y ago
In the systemctl status output, it says "Loaded: loaded (...; enabled; ...)" - "enabled" means that the service starts on boot. Use "systemctl enable" to "enable" a service. It creates a symlink in /etc/systemd/system/multi-user.target.wants assuming the service's unit file says to enable it through the "multi-user" target. By listing that directory you can see what services load on boot.
- CameronNemo 5y ago
  Not exactly. Socket units can pull in services that are not otherwise enabled. You also have to search through all of your udev rules to check if there are SYSTEMD_WANTS directives pulling services in.
  - Arnavion 5y ago
    rav (correctly) said that enabled services are started automatically on boot. They didn't say that non-enabled services are not started automatically on boot.
    - nemetroid 5y ago
      They also said: > By listing that directory you can see what services load on boot.
      - Arnavion 5y ago
        Yes, and I didn't read that sentence as disallowing other ways to autostart services either.
        nemetroid 5y ago
        To me it's equivalent to "To see what services load on boot, you can list that directory.".
  - rav 5y ago
    You're right that there's a lot of nuance to the set up. I think listing that directory will solve the "it's 4:00 am and you want to know if nginx will start on boot" scenario, but you're right that you need to understand the system in more detail if you were to build tooling around it.
viraptor 5y ago
The answer is there in the status output: Loaded: loaded ... ; enabled ... If it's enabled and starts from the service file currently, you can expect that it will start after a reboot. Of course you can never be sure it's successful, but at least it will attempt to.
corty 5y ago
Problem with systemd is, startup is not deterministic. systemd starts everything it can start at the same time, leading to subtle race conditions between services and the network. If you have any dependency that isn't explicitly spelled out or any service that is falsely reported as ready, you will get funny system states on some boots, whereas it will work on others. systemd-udev does its part to make things even worse there, because it also introduces more races against kernel devices. So with systemd, even when you tested the system, you can not always be sure that it will start everything properly. Compared to sysv-init this is a regression, because init scripts usually ran sequentially and also didn't involve unreliable systemd-udev events. Compared to Solaris SMF this is pitiful. SMF takes into account service dependencies from its declarative service descriptions and computes a deterministic sequential startup order. If it has booted once, it will always boot again, in the same order, reliably. Best of all worlds.
- viraptor 5y ago
  > Compared to sysv-init this is a regression, because init scripts usually ran sequentially and also didn't involve unreliable systemd-udev events. This goes both ways - compared to sysv-init we finally get a good way to manage services in response to device changes.
  - corty 5y ago
    It depends on the application. For laptops, sure, hotplugging stuff is important. For servers, not so much, reliability is far more important than getting your USB-stick automatically recognized. systemd is heavily skewed towards the unreliable but fast and dynamic laptop usecase.
    - viraptor 5y ago
      A server won't have many udev messages happening after boot, (Past the drive and network cards) so it shouldn't hold up and services either. Have you got specific situations in mind that are not reliable?

by memco 5y ago

rav 5y ago

In the systemctl status output, it says "Loaded: loaded (...; enabled; ...)" - "enabled" means that the service starts on boot. Use "systemctl enable" to "enable" a service. It creates a symlink in /etc/systemd/system/multi-user.target.wants assuming the service's unit file says to enable it through the "multi-user" target. By listing that directory you can see what services load on boot.

CameronNemo 5y ago
Not exactly. Socket units can pull in services that are not otherwise enabled. You also have to search through all of your udev rules to check if there are SYSTEMD_WANTS directives pulling services in.
- Arnavion 5y ago
  rav (correctly) said that enabled services are started automatically on boot. They didn't say that non-enabled services are not started automatically on boot.
  - nemetroid 5y ago
    They also said: > By listing that directory you can see what services load on boot.
    - Arnavion 5y ago
      Yes, and I didn't read that sentence as disallowing other ways to autostart services either.
      - nemetroid 5y ago
        To me it's equivalent to "To see what services load on boot, you can list that directory.".
- rav 5y ago
  You're right that there's a lot of nuance to the set up. I think listing that directory will solve the "it's 4:00 am and you want to know if nginx will start on boot" scenario, but you're right that you need to understand the system in more detail if you were to build tooling around it.

viraptor 5y ago

The answer is there in the status output: Loaded: loaded ... ; enabled ... If it's enabled and starts from the service file currently, you can expect that it will start after a reboot. Of course you can never be sure it's successful, but at least it will attempt to.

corty 5y ago

Problem with systemd is, startup is not deterministic. systemd starts everything it can start at the same time, leading to subtle race conditions between services and the network. If you have any dependency that isn't explicitly spelled out or any service that is falsely reported as ready, you will get funny system states on some boots, whereas it will work on others. systemd-udev does its part to make things even worse there, because it also introduces more races against kernel devices. So with systemd, even when you tested the system, you can not always be sure that it will start everything properly. Compared to sysv-init this is a regression, because init scripts usually ran sequentially and also didn't involve unreliable systemd-udev events. Compared to Solaris SMF this is pitiful. SMF takes into account service dependencies from its declarative service descriptions and computes a deterministic sequential startup order. If it has booted once, it will always boot again, in the same order, reliably. Best of all worlds.

viraptor 5y ago
> Compared to sysv-init this is a regression, because init scripts usually ran sequentially and also didn't involve unreliable systemd-udev events. This goes both ways - compared to sysv-init we finally get a good way to manage services in response to device changes.
- corty 5y ago
  It depends on the application. For laptops, sure, hotplugging stuff is important. For servers, not so much, reliability is far more important than getting your USB-stick automatically recognized. systemd is heavily skewed towards the unreliable but fast and dynamic laptop usecase.
  - viraptor 5y ago
    A server won't have many udev messages happening after boot, (Past the drive and network cards) so it shouldn't hold up and services either. Have you got specific situations in mind that are not reliable?