This shows you the differences between two versions of the page.
forum:inews:automated-dbsort [2007/07/15 11:49] andreas created |
forum:inews:automated-dbsort [2023/11/19 22:46] (current) |
||
---|---|---|---|
Line 3: | Line 3: | ||
====== Automated dbsort ====== | ====== Automated dbsort ====== | ||
+ | == Problem == | ||
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. | 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. | 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. In that case you can prevent users from ordering. Simply don't give them the permission to reorder stories. Of course that's not a general option because some users definitely need to reorder stories. | + | 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. | 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. | ||
+ | |||
+ | == Setup == | ||
+ | - Script - Linux shell as user root (su) on **both** machines - a and b, respectively. | ||
+ | * Create a directory ''/site/scripts/resort'' | ||
+ | * Inside ''/site/scripts/resort'' create a file ''resort.sh'' with following content:<code bash> | ||
+ | #! /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</code> | ||
+ | * Set permissions for resort.sh with<code bash> | ||
+ | chmod 744 /site/scripts/resort/resort.sh</code> | ||
+ | * Test the script.<code bash> | ||
+ | /site/scripts/resort/resort.sh</code> | ||
+ | - Crontab entry to start the script on a regularly base | ||
+ | * Add an entry to roots crontab like<code> | ||
+ | 3,8,13,18,23,28,33,38,43,48,53,58 * * * * /site/scripts/resort/resort.sh > /dev/null 2&>1</code>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. | ||
+ | == Comments == | ||
+ | * Because of the ''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: // | //Andreas Hartmann, 15.07.2007 13:36: // |