Mailing List Subscriber wrote:
> Daniel Liston <dliston@sonny.org> said:
>
>
>>You may want to consider examining this section of the majordomo.cf file;
>>
>># You can force Majordomo to delay any processing if the system load is too
>># high by uncommenting the following lines. THIS ONLY WORKS if
>
> your "uptime"
>
>># command (usually found in /usr/bin/uptime or /usr/bsd/uptime)
>># returns a string like:
>># 5:23pm up 5:51, 9 users, load average: 0.19, 0.25, 0.33
>>#
>>$max_loadavg = 10; # Choose the maximum allowed load
>>#
>>$uptime = `/usr/bin/uptime` if -x '/usr/bin/uptime'; # Get system uptime
>>#$uptime = `/usr/bsd/uptime` if -x '/usr/bsd/uptime'; # or uptime is
>
> over here.
>
>>#
>>($avg_1_minute, $avg_5_minutes, $avg_15_minutes) =
>> $uptime =~ /average:\s+(\S+),\s+(\S+),\s+(\S+)/;
>>#
>>exit 75 if ($avg_15_minutes >= $max_loadavg); # E_TEMPFAIL
>>#
>>
>>Tune to your specific needs of course. On my little 400Mhz single proc
>>intel box, I set $max_loadavg=2.
>>
>>Dan Liston
>
>
> Dan;
>
> My question is whether this simply delays processing, or does it throw an
> error back to the sender of the message. If majordomo barfs an error back at
> the sender I don't want to use it. But if it silently waits for the load
> average to go down, then I'm absolutely going to implement it.
>
> If it barfs an error back to the sender, does it just completely exit and not
> do anything with the original email? "exit 76" (an unknown error to me)
> looks pretty fatal, so "...to delay processing..." seems misleading.
>
You just need to look a little closer at the config. exit "75" and the
comment at the end of the line; #E_TEMPFAIL. Basically, this just means
the messages will be queued for later processing. Of course, if you
have the means to run the load up on your test server, you could always
just "try" it. ;)
Dan
References:
|
|
