I meant to comment on this...
> On Wed, Sep 09, 1998 at 10:51:35AM -0500, Grant Edwards wrote:
> > On Wed, Sep 09, 1998 at 11:21:58AM +0200, Svenn Are Bjerkem wrote:
> >
> > > dctrl is too fast. It opens the communication pipe before the operating
> > > system has managed to create it. At least that was what happened on my
> > > machine. I inserted some code into dctrl.
> > >
> > > (diff on the distributed dctrl < against my dctrl > )
> > >
> > > 224c224,225
> > > < catch {exec mkfifo -m 0600 $monfifo}
> > > ---
> > > > catch {exec mkfifo -m 0666 $monfifo}
> > > > after 2000
This doesn't make sense exactly. The "exec mkfifo" will not
return until the mkfifo has exited, and the fifo is
created. I.E. I don't think the problem is that dctrl
moves onward before the fifo is created.
One problem may be that the catch is masking the error. One
um-er- feature of tcl is that an exec will give you an error
if anything is sent to stderr by the program. The catch
masks the error. It might be interesting to look at the
result. I.E.
if [catch {exec mkfifo -m 0666 $monfifo} result] {
puts "ERROR: mkfifo $result"
}
> >
> > It works for me:
> >
> > Red Hat Linux release 5.1 (Manhattan)
> > Kernel 2.0.35 on a sparc
>
It may very well have masked some other timing-related problem.
> It doesn't work now. I don't know what I did to break it, but now I'm
> getting FIFO errors again:
>
> diald[1852]: FIFO: full monitor connection to monitor /tmp/dctrl.1915 requested
> diald[1852]: FIFO: could not open pipe /tmp/dctrl.1915: Device not configured
>
> The above message appears 2 seconds after dctrl starts, so I'm pretty sure
> the "after" is working as advertised.
>
Sounds like a job for strace[1] on diald, and then dctrl. You can use
the -e trace=... options to strace to cut out a lot of the noise.
Good luck,
-- cary
[1] But it seems like that's my solution to everything these days!
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
