This morning, the computer that hosts my Web-site received a routine update to its PHP 5 interpreter – i.e. to some of the modules of its PHP 5 system – which also triggered a routine restart of the Apache server processes. This has taken place without causing the slightest disruption to my site.
What most Linux-based services do, during a log-rotation, is also to restart, so that after the log-files have been renamed, the services obtain a new file-handle as well, and so that the actual writing of log data resumes with a newly-created log-file. Apache tends to be atypical, in that one of its available commands is to reload its configuration and/or its log-files. Thus, usually, the main Apache service just keeps running.
Technically, this morning, the Apache server was gone for two seconds. But, if an average reader was to find that this interfered with his browsing, he would have been able to fix that, just by clicking on the same URL a second time.
Also, my blog consists of PHP scripts, which every HTTP request executes independently of the other requests. Persistence is achieved by browser-scripts, and by a MySQL database which the server-scripts access. So there is also no loss of persistence, of my site, arising from an Apache server restart.
There is another scenario which can take place, in which I attempt to achieve something with my Apache (Web) server, by editing the config files manually, and where I give the command manually, to restart the server. Since the server will normally resume operation within 2 seconds again, I do not count this as downtime either.
But what can happen after I have edited the config files, is that I give the command to restart, and that Apache does not come back up, because I have made an error. In that case the presence of my site is affected for a longer interval of time. In fact at that point, I have two routes to choose between:
- I can just skip what I was trying to achieve and revert the config file to something which allows the server to run, or
- I can press ahead and insist that I want the feature to work. In this case I need to research what I have done wrong in my configuration file, until I come up with a configuration that allows the server to run again.
In case I only choose (2) above, which is the more likely desire, then it can take some time – maybe 10 to 20 minutes – before the server is up again, and I do log this as downtime.
However, in practice, I usually do both (1) and (2) above,
- I immediately revert the config file, so that the server runs,
- I read on the Internet, what the correct way is to change the config file in question,
- I try again.
Because this approach does not actually black out the server for more than a minute at a time, I would not log this as downtime.
In a case like this, it is immensely helpful to me, to possess a (command-line) terminal window – named “” – that offers multi-tabbed sessions. Typically, I could have 3 or more tabs open, all in mode, and one could have its set to where I can restart the service, another can have its set to where I can output the log file, and yet another can have its set to the location of the configuration file, which I am editing…