4 ms·

I think packages starting services at install time or restarting them during upgrades is primarily Debian/Ubuntu weirdness; I don't remember seeing this behavio

I think packages starting services at install time or restarting them during upgrades is primarily Debian/Ubuntu weirdness; I don't remember seeing this behaviour with RedHat or Fedora. Automatic startup on install is supremely annoying. There's a way to disable it on Debian at least, but it's terrible as default behaviour

cryptonector 8y ago
SVR4 pkgs could and did do this too. I don't think it's so out of the mainstream, but it does suck.
- Annatar 8y ago
  Well, considering I’m the one with 74000 servers here for whom this automatic restart via package postinstall works and works wonderfully, we are going to disagree and I’m going to continue doing what I’m doing the way I’ve been doing it for the past 20 years across IRIX, HP-UX and Solaris since it provides total automation. You’re welcome to continue theorizing but I’m the one here with a real world use case, and this approach works great. Since this is my specialty, there is a miniscule chance that I might know what I’m doing and what I’m writing about, however small and unenviable that chance might be.
  - chousuke 8y ago
    I'm curious how that actually works in practice. Do you package all software by yourself? I mean, if the vendor-provided httpd package for example started and enabled itself upon installation, how would you structure your configuration packages so that httpd does not start until it's actually configured? Or (theoretically) if you needed to deploy a configuration change and an upgrade simultaneously and can't restart the software before the new configuration is in place. I see this being rather easy if the vendor package simply puts the binaries in place so you can have your own packages run whatever scripts it is you need and depend on the vendor package, but I don't see how it wouldn't be a headache if the vendor package contained scripts to manage the service as well, which is what primarily annoys me on Debian-likes.
    - Annatar 8y ago
      The application package delivers only the application payload and integration with the OS; it does not start anything unless it sees its own processes running, in which case this must be an in-place upgrade, so restart the daemon(s) to unload the old and load the new code. It is the *-conf package which depends on the application package, brings on the configuration and automatically (re)starts the application.
X-Istence 8y ago
Red Hat/CentOS does this too...
- chousuke 8y ago
  They do? I admin primarily RH and CentOS hosts and I've not noticed this happening with any packages. As a quick test, I installed httpd on my workstation, and it did not get automatically started or even enabled at boot. I don't think there's anything wrong with using packages to control which software is running if you do it right, but I do think it shouldn't be default behaviour.
  - X-Istence 8y ago
    Might just be the MongoDB package then? That's the most recent one where I've noticed that upgrading the package caused MongoDB to be restarted.

cryptonector 8y ago

SVR4 pkgs could and did do this too. I don't think it's so out of the mainstream, but it does suck.

Annatar 8y ago
Well, considering I’m the one with 74000 servers here for whom this automatic restart via package postinstall works and works wonderfully, we are going to disagree and I’m going to continue doing what I’m doing the way I’ve been doing it for the past 20 years across IRIX, HP-UX and Solaris since it provides total automation. You’re welcome to continue theorizing but I’m the one here with a real world use case, and this approach works great. Since this is my specialty, there is a miniscule chance that I might know what I’m doing and what I’m writing about, however small and unenviable that chance might be.
- chousuke 8y ago
  I'm curious how that actually works in practice. Do you package all software by yourself? I mean, if the vendor-provided httpd package for example started and enabled itself upon installation, how would you structure your configuration packages so that httpd does not start until it's actually configured? Or (theoretically) if you needed to deploy a configuration change and an upgrade simultaneously and can't restart the software before the new configuration is in place. I see this being rather easy if the vendor package simply puts the binaries in place so you can have your own packages run whatever scripts it is you need and depend on the vendor package, but I don't see how it wouldn't be a headache if the vendor package contained scripts to manage the service as well, which is what primarily annoys me on Debian-likes.
  - Annatar 8y ago
    The application package delivers only the application payload and integration with the OS; it does not start anything unless it sees its own processes running, in which case this must be an in-place upgrade, so restart the daemon(s) to unload the old and load the new code. It is the *-conf package which depends on the application package, brings on the configuration and automatically (re)starts the application.

X-Istence 8y ago

Red Hat/CentOS does this too...

chousuke 8y ago
They do? I admin primarily RH and CentOS hosts and I've not noticed this happening with any packages. As a quick test, I installed httpd on my workstation, and it did not get automatically started or even enabled at boot. I don't think there's anything wrong with using packages to control which software is running if you do it right, but I do think it shouldn't be default behaviour.
- X-Istence 8y ago
  Might just be the MongoDB package then? That's the most recent one where I've noticed that upgrading the package caused MongoDB to be restarted.