You are not logged in.
Hello,
I am wondering if it is advised to call systemctl via alpm hooks for package installation (especially upgrade and remove)
For eg:
When package httpd is upgraded - shouldn't we add alpm hook to restart httpd if it is already running? (PostTransaction)
/usr/bin/systemctl try-restart httpd.service
When package httpd is removed shouldn't we add a hook which will stop and disable httpd? (PreTransaction)
/usr/bin/systemctl --now disable httpd.service
I believe only problem here is pacman may be running in chroot and systemctl may not trigger correctly.
But most Arch users hardly upgrade or remove package in chroot. (unless there is issue and booting through live CD)
So to take care of such situations we can have additional parameter in [Action] section
Say for e.g:
NotIfChroot
which means dont run (exec) the action script if in chroot.
Please give your inputs and suggestions.
Thank you
Reference Link:
https://www.archlinux.org/pacman/alpm-h … l#_actions
Last edited by amish (2017-05-09 11:30:24)
Offline
When package httpd is upgraded - shouldn't we add alpm hook to restart httpd if it is already running?
...
When package httpd is removed shouldn't we add a hook which will stop and disable httpd?
No. Definitely not!
I don't know if there might be reasonable use cases for what you suggest, but these would definitely not be acceptable. Frankly I can't imagine *any* time that it would be ok to start/stop services in hooks - at most, if you have a package that when upgraded it really must be immediately restarted, then echo a message to the user informing them of this need. Do not ever stop/start/restart long* running services for the user.
(*edit: or short ones, or instantaneous ones, or medium length ones ... just don't, ever)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
I would like to know the reason for "not be acceptable".
Like what will happen if its implemented?
Will it conflict with something?
Isnt any administrator "expected" to restart service anyway after package is upgraded? So isnt it better to have "try-restart"?
Isnt any administrator "expected" to stop and disable service if package is removed?
If yes, then why not have it in alpm hooks?
If no, please give reason - why no?
Please give link if something similar is already discussed somewhere.
Thank you
PS: httpd was just used as example. It can be any service.
Offline
Noticed your edit:
if you have a package that when upgraded it really must be immediately restarted,
If it is MUST - then why not do it via alpm? (or even install file)
Do not ever stop/start/restart long* running services for the user.
Why? Your 2 statements kind of conflict each other.... one says "MUST" restart (but u insist manually) and 2nd says "DONT do it automatically"
But if it is MUST then why not do it automatically?
Last edited by amish (2017-05-09 11:56:55)
Offline
If the config files for a service need changing when the application is upgraded, then automatically restarting could cause the service to fail.
By not restarting the user has the chance to merge any .pacnew files before (re)starting the new version, leading to zero downtime.
Last edited by Slithery (2017-05-09 12:01:50)
Offline
If the user/administrator needs to restart a service, tell them to. All the examples so far are like putting a reboot command in the post install hooks for the kernel.
Forget the "must" part, that was clearly miscommunicated. With some package upates it is important that the service be restarted: if that is the case then inform the user of this, do not try to do it for them without their consent. If it is not important that the service be restarted with a given update (quite common) then do not do anything at all.
The real problem is not the issues we could forsee, it's the ones we can't. This is just not something that is in the pervue of the package, and it should not be done. When I restart services I can opt to do so when traffic is at a lul, or I could even post an announcement that there may be a breif interruption of some services. If something goes wrong when I restart my server, then it's on me and I'll fix it. If something goes wrong because some packager wanted to be "clever" and coded in irresponsible behavior, then it's time to find new packagers and/or a new distro. Don't try to be clever, try to be reliable.
(Luckily, in my expereince our arch linux packagers are reliable. They can certainly be clever too, but they don't try to mix in clever shortcuts for the heck of it - they produce reliable packages.)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
First of all I am suggesting a feature and asking for opinion (and learning)
I am not trying to force anything.
We probably need to find how many times package upgrade actually breaks the service on restart. (due to config changes)
And how many time it is just upgrade and do a manual restart. (without needing any config changes)
If 2nd case is highly likely then auto-restart may be considered by package maintainer.
For packages that do not require restart, package maintainer will not have hook anyway.
Also config changes that require manual intervention - happens mainly for major version changes.
In that case alpm-hooks can have additional version criteria (just like it has "depends" criteria) where if upgrade is going to break something - then dont restart.
But I think currently alpm-hooks do not support version checking. So currently its not possible to solve all issues of having systemctl in alpm-hooks.
May be install file can be used instead of alpm-hooks as install file supports version checking.
But as far as this thread is considered. I rest my case..
PS: Haven't used Fedora from 3-4 yrs now but I think Fedora (and CentOS) does "restart" / "stop" related services when RPM package is upgraded or removed.
Last edited by amish (2017-05-09 12:57:59)
Offline
PS: Haven't used Fedora from 3-4 yrs now but I think Fedora (and CentOS) does "restart" / "stop" related services when RPM package is upgraded or removed.
Thanks for giving another reason to stay away from them.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
And how many time it is just upgrade and do a manual restart. (without needing any config changes)
Just because it doesn't break anything in 95% of the cases, it still doesn't justify the 5% when it does.
PS: Haven't used Fedora from 3-4 yrs now but I think Fedora (and CentOS) does "restart" / "stop" related services when RPM package is upgraded or removed.
In Debian, `apt` does that, too. It also auto-starts a service whenever a package is newly installed. And it annoys the hell out of me everytime it happens, because it feels like the machine is making decisions for me behind my back.
If there's ever a discussion on whether or not to add such a feature to pacman, count me in on the "vehemently opposing" side. It is one of the reasons why I like pacman (or dislike Debian's policy for apt).
Last edited by ayekat (2017-05-09 13:09:24)
Offline
amish wrote:And how many time it is just upgrade and do a manual restart. (without needing any config changes)
Just because it doesn't break anything in 95% of the cases, it still doesn't justify the 5% when it does.
This. But even more to the point: restarting services automatically on package install/upgrade serves no purpose other than to not break anything 95% of the time while not restarting services automatically serves no purpose other than to not break anything 100% of the time.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
Personally I am huge fan of Arch (and pacman / PKGBUILD)
But if Debian and Fedora is doing it that way, they must have found a way of NOT breaking things. (and annoy administrator frequently)
Its not like they are doing it without evaluating anything. Afterall they are also equally popular distros and used in many server.
Even they must have given a "good" thought to this.
What I also found is "systemd" guys provide macros to achieve such tasks for packagers. (of restarting / stopping services on package install)
Ofcourse currently such macros are rpm specific only (and its disabled in arch PKGBUILD of systemd)
But yes I agree that every distro has their own choices of how things should work..
And this is how Arch prefers.
Last edited by amish (2017-05-09 14:30:40)
Offline
May be pacman.conf can have something like "AlpmAutoConsent=false" (as default).
alpm hooks can have additional ACTION parameter called "RunIfAutoConsent". Such hooks run only if AlpmAutoConsent=true.
That way it will suffice for both types of administrators.
Those who prefer to do it manually (and dont want things to break at any cost) and those who want things happening automatically (but ok with things breaking once in a while)
For example:
[Trigger]
Operation = Upgrade
Type = Package
Target = apache
[Action]
Description = Restart httpd
When = PostTransaction
Exec = /usr/bin/systemctl try-restart httpd.service
RunIfAutoConsent
Last edited by amish (2017-05-09 14:50:59)
Offline
Strange you should concentrate on httpd because this is one of the few packages that is safe to restart on production systems. There's no point in adding general setting in to Pacman or aplm because very few packages have the extra code or usage scenario needed to support a graceful restart without interrupting service.
Pacman can't control service restarts anyways. The package maker gets to decide if the service auto starts, stops, and restarts, or not. We generally stick with the Arch Way unless there's a need to do otherwise. If you want an httpd package that does that, make it!
Not auto starting services is a major attraction to Arch for me. If you don't know how to start them, you also don't know how to stop them.
Offline