| View previous topic :: View next topic |
| Author |
Message |
jmglov
Retired Dev
Joined: 03 Aug 2002
Posts: 23
Location: Yokohama, Japan
|
 Posted: Wed Aug 14, 2002 11:48 pm Post subject: Minimising downtime of essential services during emerge |
 |
|
I searched the forums several times and came up blank on this, so please forgive me if the following is already common knowledge.
I wrote the following script to help me minimise the downtime of essential services (like mail or syslog) while upgrading them. I have had a couple of bad problems caused when I did an emerge that upgraded a program that was currently running as a daemon or upgraded the underlying system libraries (e.g. glibc).
However, turning said daemons off for the duration of the emerge process is decidedly sub-optimal. Therefore, I wrote a script that would, by default, take an ebuild file through the fetch, unpack, compile, and install ebuild commands, but not the qmerge. The result is that the package is built and installed into the Portage build directory. The qmerge command is what causes the package to be merged into the actual directories on the system and entered into the package database. The script also allows you to run the qmerge and/or clean ebuild commands to finalise the package's installation.
So, I use the script like this:
| Code: |
# I want to upgrade postfix, so
softmerge /usr/portage/net-mail/postfix/postfix-1.1.11-r5.ebuild
# After the smoke clears from the compilation...
etc /init.d/postfix stop
# Finalise the install, and clean up afterwards (just like emerge! :)
softmerge /usr/portage/net-mail/postfix/postfix-1.1.11-r5.ebuild \
qmerge clean
# Get mail going again
etc /init.d/postfix start
|
You can grab a copy of the script from the below link if copying from a code black does strange things.
http://www.cs.wm.edu/~jmglov/unix/scripts/softmerge
Otherwise, here is the script:
| Code: |
#!/bin/bash
#
# ==============================================
# Copyright 2002 Josh Glover <jmglov@wm.edu>
#
# This script may be used for any purpose. No warranty is expressed,
# implied, or given, of course, so Use At Your Own Risk(tm). The author
# asks only that you give him credit where he deserves it, and if you have
# suggestions or corrections, please email them to him at
# jmglov@wm.edu.
#
# softmerge
#
# Josh Glover 2002/08/14
#
# softmerge takes an ebuild through all of the same steps as emerge,
# except for the final qmerge command. This entails a fetch, unpack,
# compile, and install (see the ebuild(1) man page for more info).
# Basically, it provides a way to upgrade a critical part of a running
# system (such as postfix) without having to stop the service for the
# length of the emerge(1) process.
#
# Usage: softmerge <ebuild_file> [qmerge] [clean]
#
# Where <ebuild_file> is the full patch to an ebuild file.
# If the qmerge command is specified, the ebuild will not be run through
# the first few steps, only the qmerge (and possibly clean, if that is
# also specified).
# If the clean command is specified, the temp directory for the ebuild
# will be cleaned out. It makes sense to specify clean *after* qmerge,
# but not before, or it will prevent the qmerge from working.
# ==============================================
# Config constants
ebuild_cmd=/usr/sbin/ebuild
# Spew a warning message if the user is not root
if [ "$USER" != "root" ]; then
echo 'You most likely need to be root to run softmerge'
fi
# The ebuild file must be the first argument, so grab it
ebuild_file=$1; shift
# Initialise the ebuild command list to the empty string
ebuild_args=""
# If there are any arguments after the ebuild file, run them as
# ebuild commands
if [ -n "$1" ]; then
# Suck the commands off of the arg list
while [ -n "$1" ]; do
# Make sure the commands are either qmerge or clean
if [ "$1" == "qmerge" -o "$1" == "clean" ]; then
ebuild_args="$ebuild_args $1"
shift
else
# An illegal command was specified, say as much and exit
echo "$1 command is not supported by softmerge"
exit 1
fi
done
else
# Otherwise, undertake the normal behaviour
ebuild_args="fetch unpack compile install"
fi
# Actually run the command
$ebuild_cmd $ebuild_file $ebuild_args
# Exit with the status of the ebuild command
exit $?
|
I hope that:
- this script is of some help to someone, and
- that I am not moronically overlooking something
--Josh "This is my first post, be gentle" Glover |
|
| Back to top |
|
 |
delta407
Bodhisattva
Joined: 23 Apr 2002
Posts: 2876
Location: Chicago, IL
|
| Posted: Thu Aug 15, 2002 3:36 am Post subject: Re: Minimising downtime of essential services during emerge |
|
|
| jmglov wrote: | | I wrote the following script to help me minimise the downtime of essential services (like mail or syslog) while upgrading them. I have had a couple of bad problems caused when I did an emerge that upgraded a program that was currently running as a daemon or upgraded the underlying system libraries (e.g. glibc). |
glibc generally isn't a good idea to play around with, but the Linux shared library system [usually] plays nicely. I and many others have upgraded glibc and lots of other things without shutting down services, but as always, your mileage may vary.
| jmglov wrote: | | Therefore, I wrote a script ... |
Very cool. 
_________________
I don't believe in witty sigs. |
|
| Back to top |
|
|
jmglov
Retired Dev
Joined: 03 Aug 2002
Posts: 23
Location: Yokohama, Japan
|
| Posted: Thu Aug 15, 2002 3:49 pm Post subject: Re: Minimising downtime of essential services during emerge |
|
|
| delta407 wrote: |
glibc generally isn't a good idea to play around with, [...]
|
Ha! I scoff at your careful attitude! ;) No, you are right, I typically do not attempt to upgrade glibc on a running production system without a damned good reason.
| delta407 wrote: |
but the Linux shared library system [usually] plays nicely. I and many others have upgraded glibc and lots of other things without shutting down services, but as always, your mileage may vary.
|
It is that variance of mileage that got me. ;) I broke postfix once because I left the daemon running while I was emerging *something* (bugger if I can remember what it was now, but...). After the emerge finished, postfix started logging a bunch of errors and did not get better even with a HUP or restart of the daemon. I ended up having to re-emerge it, costing me a few minutes worth of my email (which I had to pull off another server--what a pain! ;).
--Josh Glover |
|
| Back to top |
|
|
delta407
Bodhisattva
Joined: 23 Apr 2002
Posts: 2876
Location: Chicago, IL
|
| Posted: Fri Aug 16, 2002 3:33 am Post subject: Re: Minimising downtime of essential services during emerge |
|
|
| jmglov wrote: | I ended up having to re-emerge it, costing me a few minutes worth of my email (which I had to pull off another server--what a pain!  . |
Wait, you mean your backup MXes don't automatically recover if the primary goes offline? I scoff at your silly mail system.
Nifty script, though.
_________________
I don't believe in witty sigs. |
|
| Back to top |
|
|
jmglov
Retired Dev
Joined: 03 Aug 2002
Posts: 23
Location: Yokohama, Japan
|
| Posted: Fri Aug 16, 2002 3:32 pm Post subject: Re: Minimising downtime of essential services during emerge |
|
|
| delta407 wrote: | | jmglov wrote: | | I ended up having to re-emerge it, costing me a few minutes worth of my email (which I had to pull off another server--what a pain! ;). |
Wait, you mean your backup MXes don't automatically recover if the primary goes offline? I scoff at your silly mail system. ;)
|
Backup MXes? Why would you need a failover? I don't understand! ;)
In my situation, my main mailserver sends a copy of my mail to my workstation, which is the Gentoo box in question. I hate having to go pull mail off the main server (using Pine, of all nasty MUAs!) and bring it back to my workstation.
I scoff at your scoffing!
--Josh |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
