MS4.x config/runtime issues

[Julian Field]

At 12:04 08/11/2002, you wrote:
>On Fri, 8 Nov 2002, Julian Field wrote:
>
> > Can you try this:
> >
> > use Sys::Syslog;
> > use Carp;
> >
> > eval { $SIG{'__DIE__'} = 'IGNORE';
> >         croak "Bye bye";
> > };
> > $SIG{'__DIE__'} = 'DEFAULT';
> > print "Hello there\n";
> >
> > and tell me what it outputs. On my system I just get "Hello there". If the
> > "__DIE__" handler isn't working as expected, it will stop with an error.
>
>Get "Hello there".
>
>In the interim I had also tried further adjustments in that area of
>Log.pm, namely simply printing a message before and after the:
>   eval { Sys::Syslog::setlogsock('unix'); };
>(in its various incarnations).
>
>This confirmed that it was successfully getting past this point.  In that
>sense all would *appear* to well.  (So I fully expected the "Hello there"
>from your test, anyway.)
>
>Another of my trials had been:
>    eval { Sys::Syslog::setlogsock('unix') ||
> Sys::Syslog::setlogsock('inet'); };
>
>Again, that had successfully passed this point, but still produced all the
>messages, including my test "{before|after} setlogsock()", and including
>the:
>    We haven't got any child processes [...]
>    We have just tried to reap a process which wasn't one of ours!
>
>So I'm reasonably happy that our signal/DIE/eval stuff is OK.
>
>Rather, it looks as though the mere attempt to do "setlogsock('unix')" is
>itself having a longer-term side-effect which causes later problems.  Am I
>hitting something odd in perl 5.6.0, I wonder?
>
>Given that we have a shared (from NetApp filers) perl installation across
>our Solaris/UNIX service we're not in a position simply to upgrade it at
>the drop of a hat.  I'd have to find some other workaround, at least in
>the short-term.
>
> > For now, you can comment out the setlogsock line.
>
>Sure, that's a fine temporary hack, for us, for the moment.
>
>Looking to the wider community, is there some way that "Log.pm" could
>itself do the &_PATH_LOG check before committing to the apparently trojan
>"setlogsock('unix')"?  (It seems ironic that our virus-scanner's
>innocent-looking "setlogsock('unix')" seems to have a infection-like
>result within itself!)

This is weird. The __DIE__ handler apparently works fine, and swallows
"croak" messages. Inside Sys::Syslog it does a croak if the macro _PATH_LOG
is not defined (which is actually a bug in Sys::Syslog). So how come with
the __DIE__ handler you still get the croak message? And it certainly
shouldn't cause it to stop completely.

That bit of code will have to back how it was (and you'll have to just
comment out the setlogsock line), until I understand DynaLoader a lot
better than I do now. I can't figure it at the moment. The bug is in
AUTOLOAD itself (in Sys::Syslog) which makes it very hard to over-ride. I
can't make it work, anyway. If someone else can, then let me know.
--
Julian Field                Teaching Systems Manager
jkf at ecs.soton.ac.uk         Dept. of Electronics & Computer Science
Tel. 023 8059 2817          University of Southampton
                             Southampton SO17 1BJ