← inews
A sorted queue is often ordered by maloperations. That can be lead to capital problems or to no harm - depending on the queue content. But it is a hassle at all.
Some sites work with sorted queues that are ordered later in the workflow. My understanding of a straight workflow is different. Either a queue is sorted or it isn't. To keep sorted queues sorted you can prevent users from ordering. Simply don't give them permission to reorder stories. Of course that's not a general option because some users definitely need to reorder stories.
In that case you can automate the resorting procedure. The following simple script is started by crontab regularly. It scans all directories and queues watching for some ordered queues. If there are some they get sorted again.
/site/scripts/resort
/site/scripts/resort
create a file resort.sh
with following content:#! /bin/bash # # resorts all sorted queues if ordered # runs every 5 minutes at 03, 08, 13 ... (via crontab) # LOGFILE=/var/log/messages LOGDATE=$(date | cut -c5-19) if /exc/ifis master then NUMBEROFQUEUES=$(expr $(/exc/list d | grep o | wc -l) - 1) if [ $NUMBEROFQUEUES != 0 ] then for QUEUE in $(/exc/list d | grep o | awk '{print $6}' | tail -$NUMBEROFQUEUES) do /exc/dbsort $QUEUE > /dev/null 2>&1 done echo "$LOGDATE localhost $(basename $0): $NUMBEROFQUEUES queue$([ $NUMBEROFQUEUES -eq 1 ] || echo s) resorted" >> $LOGFILE fi fi
chmod 744 /site/scripts/resort/resort.sh
/site/scripts/resort/resort.sh
3,8,13,18,23,28,33,38,43,48,53,58 * * * * /site/scripts/resort/resort.sh > /dev/null 2&>1
The leading parameter specify the time when the script has to run (in our case every hour at 03, 08, 13 and so on). See the man-page for more information. Type man 5 crontab
to read this man-page. The last parameters after >
prevent some error messages to get printed. You should have an entry for resort.sh
in the crontab of each iNEWS server.
ifis master
condition it's possible to setup the script and the crontab entry identically on both iNEWS machines (a and b). In a standard mode the script runs on a and in case of emergency - if b becomes the master - it automatically switches over to b. That means there is no administrative task needed like uncomment the crontab entry or anything like that.Andreas Hartmann, 15.07.2007 13:36: