lighttpd hangs when errorlog is a fifo

hi,

I'm using a FIFO for lighttpd's error log:

# mknod /var/log/lighttpd/error.fifo p
# grep fifo /etc/lighttpd/lighttpd.conf
server.errorlog  = "/var/log/lighttpd/error.fifo"

When I (re)start lighttpd, it won't server any request
unless I read at 
least once from error.fifo[0].

Strace(1) says it waits on:

open("/var/log/lighttpd/error.fifo", O_WRONLY_CREAT_APPEND_LARGEFIL
E, 0644) = 11

When read, lighttpd continues even without constantly
reading error.fifo 
- until the next restart, when I have to read the fifo again
at least 
once. My question: how comes, and: is this a bug?

Christian.

[0] http:/
/nerdbynature.de/bits/lighttpd-svn/1878/
-- 
BOFH excuse #410:

Electrical conduits in machine room are melting.

On 2007-08-26 16:59:02 +0200, Christian Kujau wrote:
> I'm using a FIFO for lighttpd's error log:
> 
> # mknod /var/log/lighttpd/error.fifo p
> # grep fifo /etc/lighttpd/lighttpd.conf
> server.errorlog  =
"/var/log/lighttpd/error.fifo"
> 
> When I (re)start lighttpd, it won't server any request
unless I read at 
> least once from error.fifo[0].
> 
> Strace(1) says it waits on:
> 
> open("/var/log/lighttpd/error.fifo",
O_WRONLY_CREAT_APPEND_LARGEFIL
E, 
> 0644) = 11

hmm what os/distro? seems to be a "bug" of your
open() implementation
rather than lighttpd.

> When read, lighttpd continues even without constantly
reading error.fifo 
> - until the next restart, when I have to read the fifo
again at least 
> once. My question: how comes, and: is this a bug?

that might just fill a buffer in the kernel and it should
block if this
buffers is full again.

in general it is expected that lighttpd block if your FD is
blocking.

  darix

-- 
           openSUSE - SUSE Linux is my linux
               openSUSE is good for you
                   www.opensuse.org

On 2007-08-26 19:41:09 +0200, Christian Kujau wrote:
> On Sun, 26 Aug 2007, Marcus Rueckert wrote:
> >>open("/var/log/lighttpd/error.fifo",

> >>O_WRONLY_CREAT_APPEND_LARGEFIL
E,
> >>0644) = 11
> >
> >hmm what os/distro? seems to be a "bug"
of your open() implementation
> >rather than lighttpd.
> 
> debian gnu/linux (i386, unstable, kernel 2.6.22.3),
glibc 2.6.1
> I'm about to boot into another kernel and a more
current version of 
> lighttpd (-trunk)
> 
> >that might just fill a buffer in the kernel and it
should block if this
> >buffers is full again.
> >
> >in general it is expected that lighttpd block if
your FD is blocking.
> 
> Hm, I'm not a programmer and I don't really understand
your last 
> remarks. Why should the fd be blocking? Do you mean
sth. is writing to 
> the fd? lsof(8) isn't showing anything access the fifo.
Upon read, it 
> shows:
> 

lighttpd is event based. so every handling of an event
blocks lighttpd
for that time. once it is done it jumps to the next event
and handles
that. so if the open call blocks on your OS, lighttpd will
block too.
you should make sure that the reader on the other side of
the fifo is
already running when you launch lighttpd.

  darix

-- 
           openSUSE - SUSE Linux is my linux
               openSUSE is good for you
                   www.opensuse.org

On Sun, 26 Aug 2007, Marcus Rueckert wrote:
> lighttpd is event based. so every handling of an event
blocks lighttpd
> for that time. once it is done it jumps to the next
event and handles
> that. so if the open call blocks on your OS, lighttpd
will block too.
> you should make sure that the reader on the other side
of the fifo is
> already running when you launch lighttpd.

Yes, this is my current workaround: have something reading
the fifo, while
lighttpd (re)starts. I wonder if other OSes might act
different, I shall
try out other systems...

thanks,
Christian.
-- 
BOFH excuse #180:

ether leak

On Mon, 27 Aug 2007, Christian Kujau wrote:

> Yes, this is my current workaround: have something
reading the fifo, while
> lighttpd (re)starts.

You should *always* have something doing a read on the fifo,
otherwise
lighttpd may block trying to write it because there's
nothing on the
other end to read it. Some systems might let you get away
with some
short writes without a reader on the other end, and buffer
them, but as
far as I know, this sort of behaviour certainly isn't
required by POSIX,
so it could be just luck when it happens on any OS, and
could change
from revision to revision.

cjs
-- 
Curt Sampson         <cjscynic.net>         +81
90 7737 2974
              http://www.starling-
software.com
The power of accurate observation is commonly called
cynicism
by those who have not got it.    --George Bernard Shaw

On Mon, Aug 27, 2007 at 08:47:45PM +0900, Curt Sampson
wrote:
<SNIP>
> other end to read it. Some systems might let you get
away with some
> short writes without a reader on the other end, and
buffer them, but as
> far as I know, this sort of behaviour certainly isn't
required by POSIX,

POSIX defines PIPE_BUF so that there is always a buffer
between writers and
readers from a pipe and all transfers are done atomically.

in Linux that value is hardcoded to 4K (8x512, where 512 is
_POSIX_PIPE_BUF
and is the minimum the POSIX requires) and as can be seen
(but can be never 
changed) by :

  $ ulimit -Sp
  8

in this case though, the blocking isn't in a write (which
should had failed
with a SIGPIPE instead) but in open and the reasoning why is
explained in
pipe(4) and shown from the excerpt below :

  The kernel maintains exactly one pipe object for each FIFO
special file
  that  is  opened  by  at least one process.  The FIFO must
be opened on
  both ends (reading and writing) before data can be 
passed.   Normally,
  opening the FIFO blocks until the other end is opened
also.

which is why, the pipe reader had to be opened before
lighttpd tries to open
the errorlog and why is probably better to rely on lighttpd
itself to do the
pipe (and anonymous one with exec/fork into another process
like cronolog) as 
enabled by applying the patch in TRAC 296 :

  http://trac.
lighttpd.net/trac/ticket/296

Carlo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27/08/07 06:52 AM, Christian Kujau wrote:
> On Sun, 26 Aug 2007, Marcus Rueckert wrote:
>> lighttpd is event based. so every handling of an
event blocks lighttpd
>> for that time. once it is done it jumps to the next
event and handles
>> that. so if the open call blocks on your OS,
lighttpd will block too.
>> you should make sure that the reader on the other
side of the fifo is
>> already running when you launch lighttpd.
> 
> Yes, this is my current workaround: have something
reading the fifo, while
> lighttpd (re)starts. I wonder if other OSes might act
different, I shall
> try out other systems...

The mentioned behavior is expected and normal. A O_RDONLY or
O_WRONLY
open will always block on a fifo if there's no writer/reader
on the
other end.

There's a workaround for that if someone's willing to code
it. If the
pipe is opened O_RDWR_NONBLOCK
the pipe will always open right away
and fill up even when there's no reader (I.e. if you
momentarily stop
reading you won't loose data). That would require some
instructions to
lighty to tell it should treat the file as a named pipe
because
O_RDWR_NONBLOCK
isn't what you want for a normal file. The simplest
would probably be just adding a pipe (|) in front of the
filename, and
have lighty detect it and act accordingly.

Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFG049y6dZ+Kt5BchYRAvAoAJsFfZy9GhEbPojePhvVNAvVa7UfXQCg
xpqD
iA2WgMn7whhKMRxgshwztlA=
=sTA9
-----END PGP SIGNATURE-----