Walter Haidinger wrote:
>
> Hi!
>
> First the good news:
> I applied the 0.16.5 patches to the diald-0.16 sources and compiled
> successfully. Fine.
>
> Now for the bad: Diald-0.16.5 would not dump monitor information.
>
> An `echo "monitor /etc/diald/modem.monitor" > /etc/diald/modem.fifo'
>
> procduced the following syslog entries:
>
> Aug 3 11:15:00 banshee diald[5463]:
> FIFO: full monitor connection to monitor /etc/diald/modem.monitor requested
> FIFO: could not open pipe /etc/diald/modem.monitor: No such file or
> directory
>
> There cannot be any permission problems because everything (echo, diald)
> were run as root. Of course fifo /etc/diald/modem.monitor does exist.
>
> Morever, it did work with previous diald-0.16 as I did not change anything
> but compile the new diald and install it.
>
> I solved the problem when I *removed* the patch (beginning at line 653 of
> diald-patch-0.16.5) in diald.c:
>
> @@ -431,7 +468,7 @@
> if (stat(fifoname,&sbuf) < 0 || !sbuf.st_mode&S_IFIFO) {
> syslog(LOG_INFO,"FIFO: %s not a pipe.",
> buf+k);
> - } else if ((fd = open(buf+k,O_WRONLY))<0) {
> + } else if ((fd = open(buf+k,O_WRONLY|O_NDELAY))<0) {
> syslog(LOG_INFO,"FIFO: could not open pipe %s: %m",
> buf+k);
> } else {
>
> That is, I cut `|O_NDELAY' and recompiled.
> Now diald-0.16.5 happily dumps monitoring info again.
>
> Can anyone dump monitor info with an unmodified diald-0.16.5 ?
>
> Regards, Walter
>
> --
> Walter Haidinger, email: [EMAIL PROTECTED]
> Student of Electrical Engineering, University of Technology, Vienna, Austria
> Address: Brunnerstr.6, A-3108 St.P�lten, Austria. Tel.: +43-2742-257191
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-diald" in
> the body of a message to [EMAIL PROTECTED]
I have patched what I think is the same problem in a different way. This
arose because dctrl
hung on me. As with others , I have applied the straight patch 5 to
diald-0.16.
Within dctrl, we have the original lines:
proc openFifo {} {
global fifofd monfifo monfd default_FIFO
# Turn off any previous monitoring
if {$monfd!=""} {close $monfd}
if {$monfifo!=""} {catch {exec rm -f $monfifo}}
# get new monitoring fifo
set fifofd [open $default_FIFO w]
set monfifo /tmp/dctrl.[pid]
catch {exec mkfifo -m 0600 $monfifo}
fifoCmd "monitor $monfifo"
set monfd [open $monfifo r]
close $nonblkmonfd
fileevent $monfd readable {stateChange}
}
My patch changes these lines to:
proc openFifo {} {
global fifofd monfifo monfd default_FIFO nonblkmonfd
# Turn off any previous monitoring
if {$monfd!=""} {close $monfd}
if {$monfifo!=""} {catch {exec rm -f $monfifo}}
# get new monitoring fifo
set fifofd [open $default_FIFO w]
set monfifo /tmp/dctrl.[pid]
catch {exec mkfifo -m 0600 $monfifo}
set nonblkmonfd [open $monfifo {RDONLY NONBLOCK}]
fifoCmd "monitor $monfifo"
set monfd [open $monfifo r]
close $nonblkmonfd
fileevent $monfd readable {stateChange}
}
As I understand it, the problem arises because the Linux Kernel refuses
to let a process open a named pipe
for writing, which is what the $monfifo pipe is, if no-one is reading
it. The same applies in reverse.
Whichever way you cut it, one process blocks awaiting the reader or
writer - whoever came first.
And whoever came first in a multiprocess environment becomes very
complicated very fast.
The diald process must never block - else one's entire TCP stack will go
bananas. So ...
I believe Walter's "de-patch" makes diald potentially block on dctrl's
behaviour - which is surely unhealthy...
My fix is to open the pipe non-blocking for read BEFORE requesting that
diald open it for writing.
Then ask diald to write to the pipe. Then open a second file-descriptor
on the pipe blocking for read.
Then close the original descriptor. And finally register events on the
blocking descriptor.
It seems to work with the original patch level 5 still in place, but I
wouldn't like to guarantee its
sanity. In particular, we have a smidgen of time during which there are
two readers on the pipe.
This is probably very dangerous... but it needs a kernel guru to tell us
all the legality of the situation.
The question is.. if diald chooses to write to the pipe whilst there are
two readers - neither of which have
issued a read call... is it a gamble as to which of the two readers gets
the data? Or will the data always be delivered to the first file
descriptor to read the pipe.
Ted Rule
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
