My original post:
> This subject has come up from time to time, but I have not yet seen the
> definitive solution.
>
> We were running Majordomo 1.93 under Perl 4.036 and OSF/1 V2.1 happily for
> months. Yesterday we upgraded the Alpha to OSF/1 V3.2, and Majordomo started
> dropping core. I installed Perl 5.001 to no avail. Following advice posted
> in this list in November, I converted all instances [I could find] of the
> string "..._at_..." (quotes are part of the string) to "...\_at_...". Still
> majordomo drops core...
Thanks for all the excellent replies from all over the globe. What a great
bunch of pros you all are.
There were two problems here. One was the version of Perl; the other was a
combination of wrong file permissions (our fault) and a programming
weakness in Majordomo.
Andy Phillips <atp_at_mssly1.mssl.ucl.ac.uk> advised getting Perl 5.001l.
Note the final "l." It's available from
ftp://ftp.netlabs.com/pub/outgoing/perl5.0/perl5.001l.tar.gz
We installed it on our OSF/1 3.2 system with the defaults that come with it
for "dec_osf." It passed all its regression tests. So far it seems to be
bug-free. Install this version (and get yourself a copy of Programming
Perl by Wall and Schwartz, published by O'Reilly) and you should be all
set for Perl.
Once we installed 5.001l, majordomo stopped dropping core, but another
problem appeared. Majordomo would appear to complete its assigned task,
but then the process would start getting bigger and bigger until it had
consumed all the available memory on the system. It would then say "Out of
Memory!" and abort, leaving a giant core file in ~majordomo. The problem
became obvious when I ran majordomo manually under 'perl -d.' Before the
OS upgrade we had changed the permissions on /var/adm, which is where
majordomo writes its log. When it does this, it tries to create a lockfile
in the same directory. The upgrade had set the permissions back to their
original, more restrictive, value, and majordomo could not create the
lockfile. When it couldn't create the lockfile, it tried to abort. But
part of the abort process is writing a log message. So it tried to create
a lockfile, and we were off and running. Recursive calls eventually
consumed all memory. Under the -d flag, Perl stopped at 100 levels of
calls, and the traceback printout made the problem obvious. We gave
majordomo its own log directory with the appropriate permissions, and
everything worked fine. Happy ending.
Here are a couple of observations that come from this episode.
1. We should avoid changing permissions or ownership of system directories.
Find some other way to do what needs to be done.
2. Programs - majordomo in this case - need to be very careful how they
code their error handlers so they avoid recommitting the original error
and getting into loops.
3. It would have been useful if Perl had detected the runaway recursion and
aborted majordomo before it consumed all the memory. It did this under -d
but not in normal mode. Perhaps Perl has a mechanism for this; if so,
majordomo should use it.
Thanks again to all the responders.
Steve Campbell
Received on Thu Jun 29 1995 - 16:42:24 NZST