httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mysterious Mose" <>
Subject Re: [users@httpd] accessing named pipe files from apache web server
Date Mon, 23 Apr 2012 14:53:59 GMT
Good morning everyone,

    This thread was a month ago, but I just thought I should follow up in
case someone else runs into this later and has the same question.

    I was able to work around this with no real problem by just spawning
off a new process and letting the parent die. I for some reason
thought that wouldn't work because stdin and stdout would go somewhere
else, but of course stdin and stdout of a spawned process default to
the same as the parent process.

    I still find it confusing that a named pipe returns a 401 error, and
it would be interesting to know why that's the error returned, but I
was able to work around my particular problem, so I'm happy for now.

Thanks to everyone who replied,

> Good morning Tom,
>     Thank you for your response! It's too bad things aren't as simple as I
> think they should be. :-)
>     I do understand how named pipes work in general on Unix, how you must
> have a reader and a writer for anything to happen.
>     If I create a named pipe and have no writer process, but then try to
> more or cat that file, it just hangs waiting for a writer. Once data
> goes in, the cat proceeds to dump it out as it should.
>     So my expectation was that apache would output nothing in response to
> the GET request until data was being written to the pipe. I figure it
> might time out after some period of nothing being written, but wasn't
> counting on that. But a 401 error seems really weird to me, and I get
> that whether or not there's a writer process on the named pipe.
>     I can accomplish what I want through CGI, but I was trying to work
> around a process time limit on a shared server. The CGI script gets
> killed if it runs too long, so my "brilliant" idea (so I thought!) was
> to use a named pipe instead, and have the CGI program spawn off a new
> process every so often to avoid being killed by the process time
> limit. So much for that idea. Sounds like it's either back to the
> drawing board, or on to a new host that doesn't impose this limit on
> CGI program runtimes. (I could understand a limit on CPU time, but
> their limit is on wall clock time, and the limit is only 2 or 3
> minutes, which seems unreasonable to me.)
> Thank You!
> MM
>> On Thu, Mar 22, 2012 at 1:56 PM, Mysterious Mose
>> <> wrote:
>>> Good morning,
>>> [â¦]
>>>    Why is this so difficult, and why aren't more people interested in
>>> doing this? It seems like such a simple thing to do. If I create a
>>> named pipe and write data to it, cat can get the data out, along with
>>> many other programs. So why is apache different? Is it intentionally
>>> trying to avoid reading data from named pipes, or is there some
>>> low-level operating system issue that makes it difficult, which cat
>>> has no problem with because it's part of the shell?
>>>    Thank you for any insight!
>> I think you are thinking about this too simply. If you mkfifo a fifo,
>> and then write data to it, you aren't actually writing data, as there
>> are no readers of the fifo yet; the writing process is blocked waiting
>> for the fifo to become writeable.
>> Similarly, how should Apache deal with serving the fifo. Should it
>> open it for both read and writes, ie allowing multiple writes to the
>> fifo to appear in a single response, or should it open it just for
>> reads, and punt as soon as one write is received. What should it do
>> when there is no data to be read from the fifo?
>> As you said, all these things are trivial, so I suggest you knock up a
>> CGI that treats FIFOs as you want them to be treated and returns the
>> data/times out as appropriate.
>> Cheers
>> Tom
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message