On Tue, 8 Mar 2005, Maarten Litmaath, CERN wrote:
> On Tue, 8 Mar 2005, Rod Walker wrote:
>
> > Hi,
> > Same problem as last time
> > $ myproxy-info -s myproxy.cern.ch -d
> > Failed reading length 0
> > Error authenticating: GSS Major Status: Some Other GSS failure
> > GSS Minor Status Error Chain:
> > (null)Error reading token
>
> It got itself into a deadlock. This is becoming quite a nuisance.
> I will consult the MyProxy mailing list and try and come up with
> a work-around for the time being. I have restarted the service.
Here is a snippet from the discussion I had with Jim Basney:
> On Tue, 8 Mar 2005, Jim Basney wrote:
>
> > [log in to unmask] wrote:
> > > On Tue, 8 Mar 2005, Jim Basney wrote:
> > > > Hello Maarten,
> > > >
> > > > I'm not aware of any deadlock problems in the MyProxy server (until
> > > > receiving your message). The MyProxy server isn't multi-threaded and
> > > > should be built with a non-threaded Globus flavor. My best guess is
> > >
> > > Hi Jim,
> > > the MyProxy server in VDT is built with gcc32dbg, but even a single-threaded
> > > program can get itself into a deadlock, e.g. due to a race condition when a
> > > signal is involved, say SIGCHLD, since we do see a dead child process here.
> >
> > Good point. I see that the myproxy-server SIGCHLD handler logs to
> > syslog if the myproxy-server is run in verbose mode. That could be the
>
> Aha! It certainly is a no-no to do anything non-trivial in a signal handler!
> In fact, in a signal handler one should only do simple things like setting a
> flag to be dealt with in the main loop.
>
> > source of the problem. Do you by any chance only see the problem when
> > running the myproxy-server in verbose mode?
In LCG the "--verbose" flag is used indeed. It turns out we can simply
switch it off, because even without that flag it logs enough details.
So, I have commented out this line in /etc/init.d/myproxy:
VERBOSE=--verbose
I have kept the chk-myproxy.sh cron job enabled for the time being.
|