4 ms·

Systemd is Godsent for people who have to administer diverse Linux boxes. I can see how people who want to run their own tight ship on their machine would balk

by sevagh 3y ago

Systemd is Godsent for people who have to administer diverse Linux boxes. I can see how people who want to run their own tight ship on their machine would balk at it. I also sort of hate the systemd-resolv and the fact that it instantly rendered worthless 99% of online guides of how to unfuck your local DNS resolution.

forinti 3y ago
I had no opinion on systemd until I found out I could configure the mount points in fstab to magically mount themselves whenever they were needed. I have a lot of network shares and some of them caused real trouble when they failed for whatever reason. Now I really appreciate it.
- pi-e-sigma 3y ago
  Various automount tools have been available since the 90s.
  - mariusor 3y ago
    Indeed, why use Dropbox, when FTP existed for decades?
    - pi-e-sigma 3y ago
      Except these automount tools provided exactly the same functionality that is currently provided by systemd. And did it better
      - bravetraveler 3y ago
        I contest 'better'. What's the difference? It's mounted... no? Allowing 'systemd' to be aware of mounts lets you create dependencies between your mounts and services. For example: 'Requires=mnt-myfs.mount' (and 'After'). Use 'PartOf' if you want the service to get restarted during an unmount/re-mount. This integration is mint! Anything not systemd [when it's already managing your services] trying to orchestrate is, by nature, second-rate One may note the removal of the fstab generator. It's overblown. Any distribution including systemd vendors it.
        pi-e-sigma 3y ago
        You obviously haven't used any of them and I have a feeling that in fact you haven't used anything but systemd because your remarks about systemd ability to create dependencies between mounts and services as something amazing is just hilarious.
        bravetraveler 3y ago
        Sigh. I was hoping to be a bit more productive. I haven't used them, obviously, I asked - 'what's the difference'. They haven't even been named. Is this a troll? You obviously miss my point. In this hypothetical I'm picturing a systemd system with services and mounts. The recommendation appeared to be... have another service [or something] try to provide something that 'systemd', which is already present, can handle completely fine. So, I repeat, what's the difference? What am I missing? What's better than having the thing managing your services also manage your mounts? Between the lines I'm saying this isn't fancy work. I want these mounted and useful relationships and that's it. They serve a purpose; I need a compelling reason to replace init.
      - deleted 3y ago
        [deleted]
  - znpy 3y ago
    Agree, but tou had to
doublerabbit 3y ago
> Systemd is Godsent for people who have to administer diverse Linux boxes. I disagree whole hearty. With 15 years of system administratorship, me and systemd don't get on. Services timing out on start-up/shutdown, "waiting x/y -- x/y retries and hijacking resolv.conf are my common two.
- acdha 3y ago
  > Services timing out on start-up, "waiting x/y -- x/y retries What would you prefer happen instead? Having seen plenty of downtime caused by not having retries or hanging indefinitely weren’t exactly improvements in my experience.
  - doublerabbit 3y ago
    Leave the service dead, or just kill -9 the process. "service didn't start, oh well" "service didn't stop, force killing it" Is just fine. It's my responsibility to ensure the service is operating correctly, not all-for-one systemd. Redhat bloatware dictating how Linux should be. I am aware that I can change the timeout of retries, but that's documentation overhead.
    - acdha 3y ago
      > Is just fine. It’s prolonged downtime, that’s what it is, and it may make the system unusable. I saw that several times during the transition period where a network outage or data center shutdown meant that some important daemons failed on startup (one of them had the concept of retrying a connection error, but not a DNS resolution failure) and the admins of the SysV boxes had to manually restart everything while the Upstart & systemd boxes recovered almost immediately. One fun case had the developer almost getting this right: they had implemented retries but without a time delay or back off so their init script maxed out its retry count in a second of “host not found” errors and then exited permanently. When you leave things like retries, logging, or dropping permissions up to each daemon you end up with a hodgepodge of incomplete implementations and things like error handling are where corners tend to get cut the most since the situations are infrequent and often hard to simulate.

by sevagh 3y ago

forinti 3y ago

I had no opinion on systemd until I found out I could configure the mount points in fstab to magically mount themselves whenever they were needed. I have a lot of network shares and some of them caused real trouble when they failed for whatever reason. Now I really appreciate it.

pi-e-sigma 3y ago
Various automount tools have been available since the 90s.
- mariusor 3y ago
  Indeed, why use Dropbox, when FTP existed for decades?
  - pi-e-sigma 3y ago
    Except these automount tools provided exactly the same functionality that is currently provided by systemd. And did it better
    - bravetraveler 3y ago
      I contest 'better'. What's the difference? It's mounted... no? Allowing 'systemd' to be aware of mounts lets you create dependencies between your mounts and services. For example: 'Requires=mnt-myfs.mount' (and 'After'). Use 'PartOf' if you want the service to get restarted during an unmount/re-mount. This integration is mint! Anything not systemd [when it's already managing your services] trying to orchestrate is, by nature, second-rate One may note the removal of the fstab generator. It's overblown. Any distribution including systemd vendors it.
      - pi-e-sigma 3y ago
        You obviously haven't used any of them and I have a feeling that in fact you haven't used anything but systemd because your remarks about systemd ability to create dependencies between mounts and services as something amazing is just hilarious.
        bravetraveler 3y ago
        Sigh. I was hoping to be a bit more productive. I haven't used them, obviously, I asked - 'what's the difference'. They haven't even been named. Is this a troll? You obviously miss my point. In this hypothetical I'm picturing a systemd system with services and mounts. The recommendation appeared to be... have another service [or something] try to provide something that 'systemd', which is already present, can handle completely fine. So, I repeat, what's the difference? What am I missing? What's better than having the thing managing your services also manage your mounts? Between the lines I'm saying this isn't fancy work. I want these mounted and useful relationships and that's it. They serve a purpose; I need a compelling reason to replace init.
    - deleted 3y ago
      [deleted]
- znpy 3y ago
  Agree, but tou had to

doublerabbit 3y ago

> Systemd is Godsent for people who have to administer diverse Linux boxes. I disagree whole hearty. With 15 years of system administratorship, me and systemd don't get on. Services timing out on start-up/shutdown, "waiting x/y -- x/y retries and hijacking resolv.conf are my common two.

acdha 3y ago
> Services timing out on start-up, "waiting x/y -- x/y retries What would you prefer happen instead? Having seen plenty of downtime caused by not having retries or hanging indefinitely weren’t exactly improvements in my experience.
- doublerabbit 3y ago
  Leave the service dead, or just kill -9 the process. "service didn't start, oh well" "service didn't stop, force killing it" Is just fine. It's my responsibility to ensure the service is operating correctly, not all-for-one systemd. Redhat bloatware dictating how Linux should be. I am aware that I can change the timeout of retries, but that's documentation overhead.
  - acdha 3y ago
    > Is just fine. It’s prolonged downtime, that’s what it is, and it may make the system unusable. I saw that several times during the transition period where a network outage or data center shutdown meant that some important daemons failed on startup (one of them had the concept of retrying a connection error, but not a DNS resolution failure) and the admins of the SysV boxes had to manually restart everything while the Upstart & systemd boxes recovered almost immediately. One fun case had the developer almost getting this right: they had implemented retries but without a time delay or back off so their init script maxed out its retry count in a second of “host not found” errors and then exited permanently. When you leave things like retries, logging, or dropping permissions up to each daemon you end up with a hodgepodge of incomplete implementations and things like error handling are where corners tend to get cut the most since the situations are infrequent and often hard to simulate.