unexpected alarms

[Jeff Anton]

In article <4889 at utzoo.UUCP> henry at utzoo.UUCP (Henry Spencer) writes:
>Does anybody know of any case where the persistence of alarms across
>exec is genuinely useful?  I personally think that just cancelling
>them altogether is the right thing to do.  My kernel mod cancels them
>only for setuid/gid programs simply because this was the minimum change
>in behavior needed to make things safe.

I have used the persistence of the alarm signal in a debatably
useful mannor.  I've a graphics program for the SUN workstation
that runs until interuption that I use in my .logout file.
In that file a command that checks if I'm on the console and if so,
sets an alarm for a minute and then execs my graphics.  I did not have
to modifiy my program to have a "time to die" option.

I'd like to keep the persistent alarm for that case.  I've written
a general process supervisor that kills programs if the load goes
to high or if it runs too long.  I think the persistant alarms
would be an easy way to limit program execution time.

Aside from the above, I think cancelling alarms across execs of
set[ug]id file would be a safer thing to do.  And, in the future,
setid programs should be written with the alarm signal in mind.
(Actually every signal should be considered where writeing these
programs.  One never knows.)
___________
C knows no bounds.
				Jeff Anton
				U.C. Berkeley
				ucbvax!anton
				anton at berkeley.ARPA