After a emerge --update world, the old (and possibly security flawed) code is still running, while tne new binairies are on disk. So i propose that after an update on a package, emerge should try to stop the running services (like postfix, openssh etc) and restart them with the new binaries. I know this can be hard to do with some things (like when kde is running, should it be restarted?), but others it can be simple. Like mentioned before, "simple" services like samba, postfix, openssh etc should be easy to restart imho. maybe after emerge updated / reinstalled all the packages it had to, it could start a series of questions like: Postfix was updated, do you want to restart this service? [Y/n]
We can't do this as described; here's why. Restarting samba is actually a pretty major operation and will cause any apps running from a SMB share to crash under Windows. so we need some more sophisticated approach.
debian restart the services afaik.
Samba and ssh *should* be fine if you only restart the master pid. All new connections will then connect to the updated daemon. Will look into this somewhere after 1.4 release.
*** Bug 8646 has been marked as a duplicate of this bug. ***
*** Bug 24734 has been marked as a duplicate of this bug. ***
This seems a little unnecessary - if you care that much you can restart it yourself, it's only a single command. Regardless, if it's not going to be done in the near future can it be marked as 'LATER'?
The argument against restarting Samba seems quite solid, however bug 24743 was marked as duplicte bug to this one(4780). Bug 24743 references exim being left in a broken state after emerging glibc, a simple restart of exim will fix this, however I was unaware that my MTA had been broken by emerging glibc. I cant accept the argument that a simple restart is all thats needed, the focus of the bug should be that the server admin is unaware that services have been left in broken state. Being the devils advocate, as i love portage but: Portage has to be considered safe to use, else how can we trust it to manage our packages. At the very least a warning could be posted to admins, one that isnt lost in thousands of lines of output after an emerge -up world. Perhaps post the warning before glibc is emerged, and require user input to confirm its emerge? Or maybe as a halfway house, packages which are safe to be restarted should be, others addressed later. Cheers, Danny
this could be semi-trivial to implement well ... that is, keep track of all the /etc/init.d scripts that are installed during an emerge ... then when it's finished run like `/etc/init.d/<script> status` to see if it's running ... if it is, output a list of all the services that are running and ask the user if they'd like to restart them
Automatic restarting of services is a "feature" I'd rather not see, but at least make it possible to turn it off globally if you do decide to implement it. I can see lots of potential problems, for example: * The ebuild writer cannot, in general, determine whether it's safe to restart a given service on my server. Any service could be critical. * A service may fail to restart due to required configuration file changes or other reasons. * The service may not have been started by the supplied init.d script but through some other means. This is a problem with other package management systems, don't make the same mistake with portage. Printing a warning is fine, but let the administrator decide when it is safe to restart the services; it's not necessarily right after the upgrade.
I wouldn't do this by default. I heard that ssh already deals--that new processes are created with the new code anyway... This would also require an automatic etc-update Basically, it's hard enough to have the messages scroll by that tell me what i need to do to run a certain program... Now, we're wanting to have mystery things to have to do, and have the application, or service restart? goofy! This bug depends on better seporation between package maintainers configuration, and local setting configuration (kind of like how debian has a nice directory full of apache config files that get included into the package maintainers version) and it depends on the e-warn logging bug... err.. feature request...
I think it would work best with something like the following scenario: # emerge -uDv world <wait a couple hours> There are 10 files in /etc that need updating. Run 'etc-update'. There are seven processes that need restarted. Run 'rc-restart' after 'etc-update'. # etc-update # rc-restart Using ldd, you could also detect the packages that need restarted because a .so changed underneath it. I think trying to build it into individual ebuilds would be asking for trouble, but scanning and having the user call a script is a method already proven to work with config files.
*** Bug 68199 has been marked as a duplicate of this bug. ***
Perhaps portage is the wrong place to restart these services. How about adding a prompt in etc-update to restart the service post config file update. If you want to use the new configurations, you can tell it then to restart. Something needs to be done to insure the new binaries get used instead of the old ones.
There are two issues here. The first is config file changes, the second is binary changes (security upgrades, etc). Perhaps portage could toss out a warning as its last action after any merge (especially those with 20+ packages :) ), eg: * 7 config files in /etc need updating, please run 'etc-update'. * When finished, restart the following services with '/etc/init.d/<svc> restart' * samba * ssh * hdparm This leaves the user/admin in control and gives a convenient list of what to work on.
I actually like the idea. The best one I've seen here is the one that prompts you whether you want to restart services. This should be done at the *end* of all merges, ie, if you emerge -uDav world, it should complete everything first and then prompt you for restarts, or something similar to etc-update, showing you a list of services that actually require restarting and by simply entering the number that service gets restarted. Yes it's dangerous to automagically just restart stuff, but sometimes one merge a lot of new stuff and can't always remember what new services has been merged on what servers (working with 10 servers here and a couple workstations...). An even cooler feature would be if the services that require restarting is stored somewhere and then one can first run etc-update before querying the list to see which services requires restarting. This will be slightly harder to implement though.
*** Bug 69771 has been marked as a duplicate of this bug. ***
I actually searched for a bug like this, but since I couldn't find one (wrong keywords I guess) I created bug 70958. I made a patch that makes emerge wait (when using the -w option) for you to press a key before it merges files to the live filesystem, enabling you to effectively stop a daemon before it gets merged. This bug is actually going beyond the scope of why I created the patch, but SpanKY referenced to it. I did it because I have had a production server come crashing down on me twice already (requiring a hard reboot) when I updated Apache. Disabling apache during the whole emerge process isn't an option, so this is my closest alternative (besides making daemons stop and start automagically during merges).
I understand that we do not want daemons to be automatically restarted by portage as a standard procedure, but it makes sense to automatically restart daemons that are KNOWN to crash or stop working after an emerge. So far I know of Apache and OpenSSH. Once the administrator notices Apache is crashing, they can login and restart the service themselves, but emergeing openssh will actually lock the admin out of the machine. I am particularly interesting in hearing more from Johan regarding what he said in comment #9. The ebuild writer can not be trusted "in general", but the ebuild writer can absolutely be trusted in specific cases. After all, this is what we have peer auditing for, and I believe this is the more sophisticated approach. I really do hope that this is not left as is, and I think a problem that prevents users from being able to ssh into their own machine should be heightened to a critical security bug,... as right now this bug is only listen as an enhancement. I disagree that only the administrator should be allowed to restart services.
Afaik, I never had any problems with emerging OpenSSH and then ssh not working any more all of a sudden. Restarting OpenSSH also doesn't kill your SSH-session, it keeps connected. Or am I seeing things wrong here?
well this is interesting stuff, but I agree with what Jason Cooper said above. The services should only be restarted after the config files have been straightened out (probably by etc-update). really if someone is running a server that is this critical I am not sure it would be a good idea for them to rely on emerge -u world to fix security problems and then automate the process of restarting services. If it is a mission critical server I think admin is better off updating the service related packages individually reviewing/updating the configs and restarting the service by hand. Perhaps just a message spit out that said warning this service needs to be restarted to use the new version. I agree that these can get lost in the endless messages. but it would be trivial to write a grep statement that would find them in the logs. I think that in this case, simple is safer. add a warning message and tell your admin friends to grep those logs! just my .02
The real problem is that a crashing apache _can_ bring a whole server down. I've seen it happen twice (hence, I wrote the patch so I could stop it before the apache binaries get overwritten).
I think at the end of an emerge process, it should check what services are running, and alert you if any of these packages were upgrade. it should do this at the *end* of the emerge process, not after a pacakge. Perhaps ther could be a variable EFFECTS_RUNNING or something, so when major packages like glibc, which whilst aren't upgrading a specific service, you would know it could effect all running processes. At the end of a --pretend it could say 'portage advises service x, y and z should be restarted after this update' or something along those lines. It would also be handy if a --restart switch could be passed too, so at the end of an update, portage could then restart services that have been efffected. # emerge --update --restart sshd That looks nice and simple to me. Thoughts?
Again, this will bypass any security fixes or updates made in the config files because they haven't been updated at this point. IMO, something should be put in place to alert etc-update that a service needs updating, then etc-update should do it (with confirmation), after all related config files have been updated. One way would be to tag all of a services config files with a comment string that etc-update looks for. With ssh for example, say there was a change in sshd_config and ssh_config. They would both contain the tag string, say: # etc-update:sshd etc-update would parse all ._cfg0000_* files and note that 2 contain "tags" for sshd. Once both of those files have been updated, etc-update can prompt the user with something like: All config files related to "sshd" have been updated, restart service? (y/n): Comments, etc. ?
I have seen users ask for this feature a lot, and I'd have to agree with all of those who want to add it to etc-update
Yes I agree as well. Restarting services on demand in etc-update would be the best solution. The idea of placing tags in the service config files is an idea but not foolproof. I cant remember right now which, but I seem to recall a few services that do not have default config files. So you could not search for those with etc-update. And then there is ofcourse the example given earlier of GLIBC. And stuff like djbdns which depens on daemon tools to start (So restarting it would require a special command to daemontools) and uses directories and filenames for configuration. Let's forget about djbdns for a moment. Portage knows all the dependencies. So what we could do: Every service config file could have a variable that describes which package it came from. (so /etc/init.d/samba would have something like #package=samba in its header). After portage finishes updating a package, it could check if currently running services depend on it. At the end of the update process, it could write a (hidden) file in a special place, with the names of all the services that should be restarted. Etc-update reads these files, and after updating all config files, it could do the resart questions. Maybe some precautions should be taken to avoid restarting services that already have been restarted since the emerge.
That sounds great, but it has far reaching implications and involves modifying portage and possibly the service scripts. We need to agree on something shorter-term, or we won't see it happen in our lifetimes :) If a program (service), doesn't have a config file, one could be added to, say, /etc/service.d/<service name> This brings me to another point, what if a service is updated but doesn't change any config files? I think the tag format should therefore be: # etc-update:<service name>:<package version> So, for openssh: # etc-update:sshd:3.9_p1-r2 Which would force etc-update to prompt for a service restart every package update. As an alternative to adding the tag to a service's config file, a separate file could be added to each service package, maybe /etc/service.d/<service name> That is probably the best method. Your point about certain services (djbdns), depending on other services to manage them is a good one, but it wouldn't really be an issue if the tag for a djbdns related service simply contained "svscan" as the service name, ie.: # etc-update:svscan:0.76-r4 (0.76-r4 is the version of daemontools) The maintainer of djbdns knows it would be managed by daemontools, so can confidently put svscan in each config file (or /etc/service.d/). I know the thought of having to modify hundreds of packages isn't nice, but it can happen over time when a package is next updated - it's only additional functionality.
Also, /etc/service.d/<service name> could be easily auto-generated by the ebuild to include the service version.
Sounds sensible to me :) Indeed I want it sooner than later. This sounds like it might actually work without to much programming work.
How about an easier approach? - get mtime and packages for /var/lib/init.d/started/* - check if a dep of those package was merged after the script was started - print a list of those scripts This would be done by a script called rc-restart (or whatever), so the user could update his configuration first and then call rc-restart. rc-restart could have a --auto option to automaticly restart needed services. It should also be possible to define a regex for scripts that don't need to be restarted and a variable for the depth of the dep-tree. Any thoughts?
This all sounds great and I can see the difficulty involved but I'd like to point out something that everyone else seems to have missed: what about executables that are linking against files that were replaced by an emerge. "lsof +L1" will give you a list of open files that are no longer on the disk. This seems like an important thing to consider. Just a thought.
Just a thought - why don't we throw out a big prominent message *before* the emerge process starts, listing all the services that will need restarting. So, something like an 'emerge -pv foo' will also tell you what services will need restarting after the emerge. The service ebuilds could be marked with something like a "NEEDS_RESTART=1", in which case the user could do an 'emerge --skip-services foo' in order to skip these (and dependencies, possibly) until (s)he is ready to restart the services. This way, any issues with replaced binaries/libraries are avoided.
I think that portage should only warn what services should be restarted after emerge -u world, but not restart them automaticaly. Or portage could warn to run etc-update and rc-restart (or whatever this would be named) afterwards if some services need to be restarted. That's the really nice idea, I wonder why isn't it still implemented. (Not the automatic service restarting, but some tool like etc-update, but to restart needed services, not to update configs)
I would request that the discussion move to the relevant list ( gentoo-portage-dev@gentoo.org ). In either case this needs more discussion with regards to a course of action and the appropriate implementation, neither of which are decided on.
*** Bug 138449 has been marked as a duplicate of this bug. ***
*** Bug 190378 has been marked as a duplicate of this bug. ***
*** Bug 212557 has been marked as a duplicate of this bug. ***
