Re: [munin-users] fw_conntrack plugin

[Steve S. <ste...@gm...>]

Seems that it's deep in the procfs code [1]. When asked to read with a
non-null offset (*ppos == 0), __do_proc_dointvec() just returns 0 (EOF).

On a side note, __do_proc_dostring() does the expected.

I think it's because an int has a fixed maximum size, and so it doesn't need
to keep the old value around (since it could change between 2 read calls).

Should we open a bug with dash for them to have a special handling of procfs
?

[1] http://lxr.linux.no/#linux+v2.6.32/kernel/sysctl.c#L2371

-- 
Steve Schnepp
http://blog.pwkf.org/


2010/8/31 Tom Feiner <fei...@gm...>

> On Tue, Aug 31, 2010 at 1:00 PM, Steve Schnepp <ste...@pw...>
> wrote:
> >> What is the problematic code in question anyway?
> >
> > It seems that dash's read() doesn't do as much buffered read than bash's.
> > So reading from some /proc files [1] doesn't work as expected.
> >
> > I'm afraid that procfs might not be fully posix compliant...
> > ( reading char by char seems to be unsupported)
> >
> > [1] Here the file is /proc/sys/net/ipv4/netfilter/ip_conntrack_max
> >
>
> Yes, this is indeed occurring only in /proc:
> ---
> ### Using bash, everything works fine:
> modprobe ip_conntrack
>
> read MAX </proc/sys/net/ipv4/netfilter/ip_conntrack_max ; echo "MAX=[$MAX]"
> MAX=[65536]
>
> ### Using dash, only the first char is read
> root@host:~# dash
> # read MAX </proc/sys/net/ipv4/netfilter/ip_conntrack_max ; echo
> "MAX=[$MAX]"
> MAX=[6]
>
> ### However, reading the same file while *not* part of /proc, works fine:
>
> # cp /proc/sys/net/ipv4/netfilter/ip_conntrack_max /tmp
> # read MAX </tmp/ip_conntrack_max ; echo "MAX=[$MAX]"
> MAX=[65536]
> ---
> This is reproduced using:
> squeeze/sid
> dash 0.5.5.1-7
> kernel: 2.6.32-5-686
>
> Tom
>