3 ms·

Speaking from experience, classic sysvinit was the bane of my existence when trying to deploy Python web applications. Having to use things like supervisor beca

by snuxoll 11y ago

Speaking from experience, classic sysvinit was the bane of my existence when trying to deploy Python web applications. Having to use things like supervisor because writing init scripts is such a pain is a hack, nothing more. Writing a 10 line systemd unit file packaged in with the RPM I use to deploy my app is much less of a headache, and I welcome the change - combined with parallel startup I don't have to block nginx from loading while my application loads (or vice-versa).

nitrogen 11y ago
Ubuntu's Upstart was also pretty nice in this regard.
- themartorana 11y ago
  Thank you. I feel like this gets overlooked. It worked well, and was easy to grok. Too bad it lost support.
  - JdeBP 11y ago
    See the "red herring" discussion in http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ and https://news.ycombinator.com/item?id=11641426 https://news.ycombinator.com/item?id=11641426 on this very page. It's definitely wrong to think that upstart was overlooked when it came to the Debian hoo-hah, furthermore. Upstart was one of the four major contenders, and one of the two front-runners.
- lomnakkus 11y ago
  It was certainly nicer than sysvinit, but its event-based model absolute hell to debug, IME. (It basically required the user to program a state machine around all the events that could happen on a system.) Just look at the bugs on Upstart in the Ubuntu bug tracker if you don't believe me. There were bugs in there that languished for years because they were basically unsolvable. The original author of Upstart basically admitted (to his credit!) that systemd's model is superior after Upstart had been in out in the wild for a few years.
- snuxoll 11y ago
  Upstarts event-driven mess made it extremely hard to debug and rationalize about your dependencies for a service. systemd's approach of a basic dependency graph for services is a lot easier to work with, plus some bonus features like socket activation and work directory creation that upstart doesn't have. I have a python webapp hosted inside uwsgi reverse proxied by nginx, adding `RuntimeDirectory=mycoolapp` to the unit file automatically creates and destroys `/run/mycoolapp` every time the unit starts and stops. I just plop my socket file inside the runtime directory (which is automatically created with the correct uid/gid based on the user/group the unit runs as) and fly away, I don't have to manage some directory inside /var/ and deal with an rpm scriplet to ensure the correct owner/group are set on it after install. It's all the little things that systemd does that really make one appreciate it, they add up.

by snuxoll 11y ago

nitrogen 11y ago

Ubuntu's Upstart was also pretty nice in this regard.

themartorana 11y ago
Thank you. I feel like this gets overlooked. It worked well, and was easy to grok. Too bad it lost support.
- JdeBP 11y ago
  See the "red herring" discussion in http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ and https://news.ycombinator.com/item?id=11641426 https://news.ycombinator.com/item?id=11641426 on this very page. It's definitely wrong to think that upstart was overlooked when it came to the Debian hoo-hah, furthermore. Upstart was one of the four major contenders, and one of the two front-runners.
lomnakkus 11y ago
It was certainly nicer than sysvinit, but its event-based model absolute hell to debug, IME. (It basically required the user to program a state machine around all the events that could happen on a system.) Just look at the bugs on Upstart in the Ubuntu bug tracker if you don't believe me. There were bugs in there that languished for years because they were basically unsolvable. The original author of Upstart basically admitted (to his credit!) that systemd's model is superior after Upstart had been in out in the wild for a few years.
snuxoll 11y ago
Upstarts event-driven mess made it extremely hard to debug and rationalize about your dependencies for a service. systemd's approach of a basic dependency graph for services is a lot easier to work with, plus some bonus features like socket activation and work directory creation that upstart doesn't have. I have a python webapp hosted inside uwsgi reverse proxied by nginx, adding `RuntimeDirectory=mycoolapp` to the unit file automatically creates and destroys `/run/mycoolapp` every time the unit starts and stops. I just plop my socket file inside the runtime directory (which is automatically created with the correct uid/gid based on the user/group the unit runs as) and fly away, I don't have to manage some directory inside /var/ and deal with an rpm scriplet to ensure the correct owner/group are set on it after install. It's all the little things that systemd does that really make one appreciate it, they add up.