Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Imaging I am running a mail server, e.g. exim4 (or a database, a syslog daemon...). Now, while updating this package I would assume the application has to be stopped or at least restarted after update. If one would send an email during this time, it would fail. Is this case considered during updates, are there any countermeasures taken or is it up to a software sending mails to send the mail again later?

share|improve this question

Normally it's up to the software sending an email to queue it up until the service becomes available. When the server is inaccessible there are multiple possible causes which means that the software sending i.e. connecting to the server has to have mechanisms to reconnect and retry the transaction(s).

On top of this I would have to ask for the logic of why are you upgrading any piece of software on your system if you know that you can't take downtime? You are downloading(?), unpacking(?) and replacing executables and possibly shared libraries for this particular piece of software, which could fail leaving you with an unusable system, so if you can't take downtime on it why are you doing this?

share|improve this answer
Even critical services can have security vulnerabilities that must be patched. – jordanm Sep 25 '12 at 13:37
@jordanm I don't doubt it. But any update or upgrade has risks of not working during or after, so if you can't take any downtime one should be looking at different solution for the problem. Wouldn't you agree? – Karlson Sep 25 '12 at 13:47
Yes, redundant servers is a good choice. – jordanm Sep 25 '12 at 13:51

There is software that can be updated without downtime. Therefor the software has to be capable to run both versions - the new and the old one - at the same time. During the update the old version still serves the clients connecting to it. After the update the new version takes over control and handles new clients. The old version is shutted down after the last client disconnects from it and then can be removed (or stay in the background as fallback mode if the new version does not work right and there are mechanisms for graceful degradation implemented.) But those mechanisms are implemented in very few use cases.

Otherwise jordanm is right with his comment about redundancy.

share|improve this answer

It depends entirely on the capabilities of the software and on the package's install/update scripts.

Some programs will keep on working as normal during an upgrade and will only need a restart when the upgrade is completed....and, usually, package maintainers take advantage of that fact with their packaging scripts.

(I usually report it as a bug when I see a package being unnecessarily stopped during upgrade as this can lead to extremely long outages on, e.g., an apt-get dist-upgrade if there are many packages to upgrade or if one of the packages being upgraded asks a question on the tty. I also tend to upgrade the most important services individually rather than as part of a dist-upgrade to minimise downtime....after testing the upgrade on non-production machines, of couse)

Other programs are not so forgiving of their environment changing while they're still running and need to be stopped during the upgrade process. Again, this is usually handled automatically by the package-maintainer's scripts.

In both cases, it is the package maintainer's job to know the software they are packaging well enough to take the most appropriate action.

share|improve this answer

Most MTAs operate by dropping emails in a queue directory, then picking up the queued files and sending them when possible. During an MTA upgrade, the daemon that sends the emails will be stopped for a short time, but if a client program sends an email, it will still be queued for processing when the daemon restarts.

In the other direction, if another server tries to contact this server and gets no answer because of the ongoing upgrade, the other server will queue the email and retry after a short interval. Email delivery is designed to be highly reliable (though it isn't as reliable as it used to be, to a large part because of the weight of spam and spam countermeasures).

For other kinds of software, there might be a small downtime while the daemon is being restarted. Such downtime is generally handled by having multiple server machines and balancing connections between them. Such redundancy is necessary for high-availability systems anyway (hardware failures can always happen).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.