Re: problem with linux 2.6.11 and sa

2005-03-21 Thread George Georgalis 
On Mon, Mar 21, 2005 at 02:25:55PM -0800, Andrew Morton wrote:
>"George Georgalis" <[EMAIL PROTECTED]> wrote:
>>
>> I'm very defiantly seeing a problem with the 2.6.11
>> kernel and my spamassassin setup. However, it's not
>> clear exactly where the problem is, seems like sa
>> but it might be 2.6.11 with daemontools + qmail +
>> QMAIL_QUEUE.
>> 
>> A sure sign of it is no logs (with debug) for
>> remote sa connections which score "0/0" and correct
>> operation with local "cat spam.txt | spamc -R"; fix
>> is to use the older kernel.
>> 
>> SA has stopped stdout logging completely with 2.6.11
>> in addition to the all pass score. But the message
>> seems to go through my temp queue (for testing) and
>> sent on to my local MDA. I'm not sure if it's a sa
>> problem with the kernel or the new kernel doing
>> something new with pipes from tcp connections.
>> Maybe the new kernel is not making files available
>> (eg 0 bytes), until the writing pipe is closed?
>> That would make my SA test a zero byte file, which
>> would pass, close, become full, and the file piped
>> to local MDA is full? ...humm then I'd get a score
>> of "0/5"... this sounds like a SA problem with the
>> new kernel, ideas?
>
>George, did you end up getting to the bottom of this?  I'd be suspecting a
>bug in the new pipe code, or an application bug which was triggered by the
>new pipe code.

Hi! No resolution, I've been overloaded on a work related project.  The
best I can say is no problem noticed with 2.6.8.1, 2.6.10 works for smtp
code below but fails mplayer commands; 2.6.11 failed smtp code, didn't
test mplayer on 2.6.11 and haven't tried any newer kernels.

while read file; do mplayer $file ; done http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with linux 2.6.11 and sa

2005-03-21 Thread Andrew Morton 
"George Georgalis" <[EMAIL PROTECTED]> wrote:
>
> I'm very defiantly seeing a problem with the 2.6.11
> kernel and my spamassassin setup. However, it's not
> clear exactly where the problem is, seems like sa
> but it might be 2.6.11 with daemontools + qmail +
> QMAIL_QUEUE.
> 
> A sure sign of it is no logs (with debug) for
> remote sa connections which score "0/0" and correct
> operation with local "cat spam.txt | spamc -R"; fix
> is to use the older kernel.
> 
> SA has stopped stdout logging completely with 2.6.11
> in addition to the all pass score. But the message
> seems to go through my temp queue (for testing) and
> sent on to my local MDA. I'm not sure if it's a sa
> problem with the kernel or the new kernel doing
> something new with pipes from tcp connections.
> Maybe the new kernel is not making files available
> (eg 0 bytes), until the writing pipe is closed?
> That would make my SA test a zero byte file, which
> would pass, close, become full, and the file piped
> to local MDA is full? ...humm then I'd get a score
> of "0/5"... this sounds like a SA problem with the
> new kernel, ideas?

George, did you end up getting to the bottom of this?  I'd be suspecting a
bug in the new pipe code, or an application bug which was triggered by the
new pipe code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with linux 2.6.11 and sa

2005-03-21 Thread Andrew Morton 
George Georgalis [EMAIL PROTECTED] wrote:

 I'm very defiantly seeing a problem with the 2.6.11
 kernel and my spamassassin setup. However, it's not
 clear exactly where the problem is, seems like sa
 but it might be 2.6.11 with daemontools + qmail +
 QMAIL_QUEUE.
 
 A sure sign of it is no logs (with debug) for
 remote sa connections which score 0/0 and correct
 operation with local cat spam.txt | spamc -R; fix
 is to use the older kernel.
 
 SA has stopped stdout logging completely with 2.6.11
 in addition to the all pass score. But the message
 seems to go through my temp queue (for testing) and
 sent on to my local MDA. I'm not sure if it's a sa
 problem with the kernel or the new kernel doing
 something new with pipes from tcp connections.
 Maybe the new kernel is not making files available
 (eg 0 bytes), until the writing pipe is closed?
 That would make my SA test a zero byte file, which
 would pass, close, become full, and the file piped
 to local MDA is full? ...humm then I'd get a score
 of 0/5... this sounds like a SA problem with the
 new kernel, ideas?

George, did you end up getting to the bottom of this?  I'd be suspecting a
bug in the new pipe code, or an application bug which was triggered by the
new pipe code.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with linux 2.6.11 and sa

2005-03-21 Thread George Georgalis 
On Mon, Mar 21, 2005 at 02:25:55PM -0800, Andrew Morton wrote:
George Georgalis [EMAIL PROTECTED] wrote:

 I'm very defiantly seeing a problem with the 2.6.11
 kernel and my spamassassin setup. However, it's not
 clear exactly where the problem is, seems like sa
 but it might be 2.6.11 with daemontools + qmail +
 QMAIL_QUEUE.
 
 A sure sign of it is no logs (with debug) for
 remote sa connections which score 0/0 and correct
 operation with local cat spam.txt | spamc -R; fix
 is to use the older kernel.
 
 SA has stopped stdout logging completely with 2.6.11
 in addition to the all pass score. But the message
 seems to go through my temp queue (for testing) and
 sent on to my local MDA. I'm not sure if it's a sa
 problem with the kernel or the new kernel doing
 something new with pipes from tcp connections.
 Maybe the new kernel is not making files available
 (eg 0 bytes), until the writing pipe is closed?
 That would make my SA test a zero byte file, which
 would pass, close, become full, and the file piped
 to local MDA is full? ...humm then I'd get a score
 of 0/5... this sounds like a SA problem with the
 new kernel, ideas?

George, did you end up getting to the bottom of this?  I'd be suspecting a
bug in the new pipe code, or an application bug which was triggered by the
new pipe code.

Hi! No resolution, I've been overloaded on a work related project.  The
best I can say is no problem noticed with 2.6.8.1, 2.6.10 works for smtp
code below but fails mplayer commands; 2.6.11 failed smtp code, didn't
test mplayer on 2.6.11 and haven't tried any newer kernels.

while read file; do mplayer $file ; done mediafiles.txt # fails

for file in `cat mediafiles.txt`; do mplayer $file ; done # works

mplayer foo.mpg # works 
mplayer foo.mpg  mediafiles.txt # confuses binary for keboard input

This is the code that seems to fail per quote above, stdin is the smtp
DATA

tmp=${scq}/`safecat ${scq}/tmp ${scq} /dev/stdin` \
|| { echo Error $?; exit 71; } # put the pipeline to disk, if possible
# ${scq}/tmp is a temp for this function ${scq} is temp for this
# program
score=`spamc -x -c $tmp` # score it with spamd
sce=$?

I saw some notes on the new multi page pipes, me thinks its related but
that's all I know...

Regards,
// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-16 Thread George Georgalis 
On Wed, Mar 16, 2005 at 05:37:59PM -0500, Paul Jarc wrote:
>"George Georgalis" <[EMAIL PROTECTED]> wrote:
>> On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
>>> To simplify, what about these two:
>>> mplayer foo.mpg
>>> mplayer foo.mpg < mediafiles.txt
>>
>> The particular host does not have X support so mpg is out.
>
>Well, use any one of the files listed in mediafiles.txt.  I expect the
>first one would behave the same as your for loop, and the second would
>behave the same as your while loop.

zz.mtest contains the full path to 3 ogg files on 3 lines, no funny
characters, the following is one of them.

$ mplayer 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg

plays fine, as expected. however, per your test:

$ mplayer 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg 
176400 (112.0 kbit)
Selected audio codec: [vorbis] afm:libvorbis (OggVorbis Audio Decoder)
==
Checking audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
AF_pre: af format: 2 bps, 2 ch, 44100 hz, little endian signed int 
AF_pre: 44100Hz 2ch Signed 16-bit (Little-Endian)
AO: [oss] 44100Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
Video: no video
Starting playback...
No bind found for key _ 
A:   0.1 (00.1) ??,?%   
No bind found for key L 
No bind found for key _ 
No bind found for key B 
No bind found for key l 
A:   0.8 (00.8)  4.3%   
  =  PAUSE  =

Exiting... (End of file)


program crashes quickly, without any keyboard interaction.

>> I'm not sure that that test would work as mplayer requires filenames
>> as command arguments not stdin (exclusivly, I think);
>
>Note that I said to redirect input from mediafiles.txt, not from any
>of the filenames listed in it, but one of the files listed in it
>should also be passed ion the command line in both cases.
>
>Your test also had mplayer's stdin connected to mediafiles.txt.  It
>was just less explicit - mplayer inherits stdin from surrounding loop.
>So I'm suggesting simplifying the test so that stdin is the *only*
>difference between the two cases, and that will show whether it's
>relevant.  OTOH, if you can't reproduce the problem with the
>simplified pair of tests, then some interaction with the shell loops
>must be involved.

per above, the problem is reproduced with your example.

v>> this works fine
>> mplayer `cat zz.mtest `
>
>> Then I tried
>> while read file; do mplayer "$file" ; done 
>What's in zz.mtest?  E.g., if it contains a line "-", then that will
>tell mplayer to play the file on stdin, which in this case is
>zz.mtest.  Choosing one of the listed files and testing with that, as
>I suggested above, will eliminate this possibility.

zz.mtest is just 3 ogg files like the one above in my first run. Me
throws up hands, I know it is kernel api change, me thinks Linux is not
posix anymore (per lkml followup). Big concern is not my ability to play
songs, but *complex* scripts to check spam during smtp are broke in
2.6.11 (rc?) and forward.

tmp="${scq}/`safecat "${scq}/tmp" "${scq}" http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-16 Thread Paul Jarc 
"George Georgalis" <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
>> To simplify, what about these two:
>> mplayer foo.mpg
>> mplayer foo.mpg < mediafiles.txt
>
> The particular host does not have X support so mpg is out.

Well, use any one of the files listed in mediafiles.txt.  I expect the
first one would behave the same as your for loop, and the second would
behave the same as your while loop.

> I'm not sure that that test would work as mplayer requires filenames
> as command arguments not stdin (exclusivly, I think);

Note that I said to redirect input from mediafiles.txt, not from any
of the filenames listed in it, but one of the files listed in it
should also be passed ion the command line in both cases.

Your test also had mplayer's stdin connected to mediafiles.txt.  It
was just less explicit - mplayer inherits stdin from surrounding loop.
So I'm suggesting simplifying the test so that stdin is the *only*
difference between the two cases, and that will show whether it's
relevant.  OTOH, if you can't reproduce the problem with the
simplified pair of tests, then some interaction with the shell loops
must be involved.

> this works fine
> mplayer `cat zz.mtest `
>
> Then I tried
> mplayer /dev/stdin  Then I tried
> while read file; do mplayer "$file" ; done http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-16 Thread Paul Jarc 
George Georgalis [EMAIL PROTECTED] wrote:
 On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
 To simplify, what about these two:
 mplayer foo.mpg
 mplayer foo.mpg  mediafiles.txt

 The particular host does not have X support so mpg is out.

Well, use any one of the files listed in mediafiles.txt.  I expect the
first one would behave the same as your for loop, and the second would
behave the same as your while loop.

 I'm not sure that that test would work as mplayer requires filenames
 as command arguments not stdin (exclusivly, I think);

Note that I said to redirect input from mediafiles.txt, not from any
of the filenames listed in it, but one of the files listed in it
should also be passed ion the command line in both cases.

Your test also had mplayer's stdin connected to mediafiles.txt.  It
was just less explicit - mplayer inherits stdin from surrounding loop.
So I'm suggesting simplifying the test so that stdin is the *only*
difference between the two cases, and that will show whether it's
relevant.  OTOH, if you can't reproduce the problem with the
simplified pair of tests, then some interaction with the shell loops
must be involved.

 this works fine
 mplayer `cat zz.mtest `

 Then I tried
 mplayer /dev/stdin zz.mtest

In the first case, mplayer is processing the files listed in
zz.mtest.  In the second case, it's processing zz.mtest itself.  So
it's not surprising that you get different results here.

 Then I tried
 while read file; do mplayer $file ; done zz.mtest

What's in zz.mtest?  E.g., if it contains a line -, then that will
tell mplayer to play the file on stdin, which in this case is
zz.mtest.  Choosing one of the listed files and testing with that, as
I suggested above, will eliminate this possibility.


paul
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-16 Thread George Georgalis 
On Wed, Mar 16, 2005 at 05:37:59PM -0500, Paul Jarc wrote:
George Georgalis [EMAIL PROTECTED] wrote:
 On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
 To simplify, what about these two:
 mplayer foo.mpg
 mplayer foo.mpg  mediafiles.txt

 The particular host does not have X support so mpg is out.

Well, use any one of the files listed in mediafiles.txt.  I expect the
first one would behave the same as your for loop, and the second would
behave the same as your while loop.

zz.mtest contains the full path to 3 ogg files on 3 lines, no funny
characters, the following is one of them.

$ mplayer 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg

plays fine, as expected. however, per your test:

$ mplayer 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg 
zz.mtest 
MPlayer 1.0pre6-2.95.4 (C) 2000-2004 MPlayer Team
CPU: IDT/Centaur/VIA C3 Nehemiah (Family: 6, Stepping: 5)
Detected cache-line size is 32 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE


Playing 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg.
Ogg file format detected.
==
Opening audio decoder: [libvorbis] Ogg/Vorbis audio decoder
AUDIO: 44100 Hz, 2 ch, 16 bit (0x10), ratio: 14001-176400 (112.0 kbit)
Selected audio codec: [vorbis] afm:libvorbis (OggVorbis Audio Decoder)
==
Checking audio filter chain for 44100Hz/2ch/16bit - 44100Hz/2ch/16bit...
AF_pre: af format: 2 bps, 2 ch, 44100 hz, little endian signed int 
AF_pre: 44100Hz 2ch Signed 16-bit (Little-Endian)
AO: [oss] 44100Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 44100Hz/2ch/16bit - 44100Hz/2ch/16bit...
Video: no video
Starting playback...
No bind found for key _ 
A:   0.1 (00.1) ??,?%   
No bind found for key L 
No bind found for key _ 
No bind found for key B 
No bind found for key l 
A:   0.8 (00.8)  4.3%   
  =  PAUSE  =

Exiting... (End of file)


program crashes quickly, without any keyboard interaction.

 I'm not sure that that test would work as mplayer requires filenames
 as command arguments not stdin (exclusivly, I think);

Note that I said to redirect input from mediafiles.txt, not from any
of the filenames listed in it, but one of the files listed in it
should also be passed ion the command line in both cases.

Your test also had mplayer's stdin connected to mediafiles.txt.  It
was just less explicit - mplayer inherits stdin from surrounding loop.
So I'm suggesting simplifying the test so that stdin is the *only*
difference between the two cases, and that will show whether it's
relevant.  OTOH, if you can't reproduce the problem with the
simplified pair of tests, then some interaction with the shell loops
must be involved.

per above, the problem is reproduced with your example.

v this works fine
 mplayer `cat zz.mtest `

 Then I tried
 while read file; do mplayer $file ; done zz.mtest

What's in zz.mtest?  E.g., if it contains a line -, then that will
tell mplayer to play the file on stdin, which in this case is
zz.mtest.  Choosing one of the listed files and testing with that, as
I suggested above, will eliminate this possibility.

zz.mtest is just 3 ogg files like the one above in my first run. Me
throws up hands, I know it is kernel api change, me thinks Linux is not
posix anymore (per lkml followup). Big concern is not my ability to play
songs, but *complex* scripts to check spam during smtp are broke in
2.6.11 (rc?) and forward.

tmp=${scq}/`safecat ${scq}/tmp ${scq} /dev/stdin` \
|| { echo Error $?; exit 71; } # put the pipeline to disk, if possible
# ${scq}/tmp is a temp for this function ${scq} is temp for this program
score=`spamc -x -c $tmp` # score it with spamd
sce=$?

... Who knows what else won't be working.

// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-15 Thread George Georgalis 
On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
>"George Georgalis" <[EMAIL PROTECTED]> wrote:
>> It (Gerrit Pape's technique) very defiantly stopped working a few revs
>> back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
>> mplayer with 2.6.10, now too.
>
>The /proc/kmsg problem happens because the kernel now checks for
>permission at read() instead of open().  The /dev/rtc problem seems to
>be a different beast.

Thanks for the kmsg clairfication, Paul.

>> while read file; do mplayer $file ; done >
>> Failed to open /dev/rtc: Permission denied
>>
>> for file in `cat mediafiles.txt`; do mplayer $file ; done
>>
>> works.
>
>To simplify, what about these two:
>mplayer foo.mpg
>mplayer foo.mpg < mediafiles.txt
>
>You might try strace'ing both cases and see how they compare.

The particular host does not have X support so mpg is out.
I'm not sure that that test would work as mplayer requires filenames
as command arguments not stdin (exclusivly, I think); my guess
is mplayer would try to decode stdin.

this works fine
mplayer `cat zz.mtest `

Then I tried
mplayer /dev/stdin  /proc/sys/dev/rtc/max-user-freq" to your system startup 
scripts.

the file almost played though...
Playing 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg.
Ogg file format detected.
...

But it seemed to take keyboard commands from the binary
No bind found for key _ 
A:   0.1 (00.1) ??,?%   
No bind found for key R 
A:   0.8 (00.8)  4.2%   

and quit.  I tried the sysctl suggestion, no change, whenever a file list
is redirected to stdin, and a filename argument is given to mplayer, eg

while read file; do mplayer "$file" ; done http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-15 Thread George Georgalis 
On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
George Georgalis [EMAIL PROTECTED] wrote:
 It (Gerrit Pape's technique) very defiantly stopped working a few revs
 back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
 mplayer with 2.6.10, now too.

The /proc/kmsg problem happens because the kernel now checks for
permission at read() instead of open().  The /dev/rtc problem seems to
be a different beast.

Thanks for the kmsg clairfication, Paul.

 while read file; do mplayer $file ; done mediafiles.txt

 Failed to open /dev/rtc: Permission denied

 for file in `cat mediafiles.txt`; do mplayer $file ; done

 works.

To simplify, what about these two:
mplayer foo.mpg
mplayer foo.mpg  mediafiles.txt

You might try strace'ing both cases and see how they compare.

The particular host does not have X support so mpg is out.
I'm not sure that that test would work as mplayer requires filenames
as command arguments not stdin (exclusivly, I think); my guess
is mplayer would try to decode stdin.

this works fine
mplayer `cat zz.mtest `

Then I tried
mplayer /dev/stdin zz.mtest

I got
Failed to open /dev/rtc: Permission denied (it should be readable by the user.)

so what the heck, I changed it...
$ ls -l /dev/rtc 
crw-rw1 root root  10, 135 Mar 14  2002 /dev/rtc
chmod o+r /dev/rtc

Then I tried
while read file; do mplayer $file ; done zz.mtest

and got
Linux RTC init error in ioctl (rtc_irqp_set 1024): Permission denied
Try adding echo 1024  /proc/sys/dev/rtc/max-user-freq to your system startup 
scripts.

the file almost played though...
Playing 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg.
Ogg file format detected.
...

But it seemed to take keyboard commands from the binary
No bind found for key _ 
A:   0.1 (00.1) ??,?%   
No bind found for key R 
A:   0.8 (00.8)  4.2%   

and quit.  I tried the sysctl suggestion, no change, whenever a file list
is redirected to stdin, and a filename argument is given to mplayer, eg

while read file; do mplayer $file ; done zz.mtest

now I don't have rtc errors but mplayer is getting strange input it
doesn't grok.

Once again, this works fine without the changed rtc perms or the sysctl
echo:

mplayer `cat zz.mtest`

I've not had a chance to properly test - I still think there is a new
kernel bug/feature but cant find time to properly track it down.

// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-09 Thread Nix 
On Wed, 09 Mar 2005, Paul Jarc uttered the following:
> "George Georgalis" <[EMAIL PROTECTED]> wrote:
>> It (Gerrit Pape's technique) very defiantly stopped working a few revs
>> back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
>> mplayer with 2.6.10, now too.
> 
> The /proc/kmsg problem happens because the kernel now checks for
> permission at read() instead of open().

Am I the only person who thinks `eee-ick, how utterly non-POSIX' at
that?

-- 
> ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-09 Thread Paul Jarc 
"George Georgalis" <[EMAIL PROTECTED]> wrote:
> It (Gerrit Pape's technique) very defiantly stopped working a few revs
> back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
> mplayer with 2.6.10, now too.

The /proc/kmsg problem happens because the kernel now checks for
permission at read() instead of open().  The /dev/rtc problem seems to
be a different beast.

> while read file; do mplayer $file ; done 
> Failed to open /dev/rtc: Permission denied
>
> for file in `cat mediafiles.txt`; do mplayer $file ; done
>
> works.

To simplify, what about these two:
mplayer foo.mpg
mplayer foo.mpg < mediafiles.txt

You might try strace'ing both cases and see how they compare.


paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-09 Thread George Georgalis 
On Wed, Mar 09, 2005 at 01:06:11PM +, Nix wrote:

>> An interesting technique that allows a program (such as a log writer)
>> to run as an unprivileged user, while receiving privileged data. (taken
>> almost verbatim from Gerrit Pape's socklog)
>> 
>> #!/bin/sh
>> exec > exec 2>&1
>> exec softlimit -m 200 setuidgid nobody socklog ucspi
>> 
>> This script, run by root takes its stdin from /proc/kmsg then combines
>> its stdout and stderr, and exec-switches to the socklog program run
>> as an ucspi application listening to the domain stream socket, as
>> nobody:nogroup, with memory consumption limited to 2Mb. (and sends
>> log to stdout)
>
>This is definitely redirection, not piping. As far as I know the
>implementation of redirection in the kernel remains unchanged: certainly
>the need to buffer piped data doesn't exist in this case, and since the
>redesign was of the buffering, this is probably not your problem :)
>
>> It worked flawlessly until several kernel revs back when the kernel
>> started protecting kmsg and wouldn't allow the user program to receive
>> it,
>
>Indeed.
>
>>   result: nothing sent to the logging program and no error. The fix
>> was to run socklog as root instead of nobody.
>
>You should be able to open it as root and read from it as another user:
>i.e., your technique above shouldn't break. (I'd hope.)

Here is a nice proof that kmsg did become a problem around 2.6.0
http://article.gmane.org/gmane.comp.misc.pape.general/595
http://thread.gmane.org/gmane.comp.misc.pape.general/590


It (Gerrit Pape's technique) very defiantly stopped working a few revs
back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
mplayer with 2.6.10, now too.

http://lkml.org/lkml/2005/3/8/226

while read file; do mplayer $file ; done http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-09 Thread Nix 
On Tue, 8 Mar 2005, George Georgalis announced authoritatively:
> Here's what I'm doing that is broken. I use tcpserver (functionally
> similar to inetd) to receive an incoming smtp connection. While the
> smtp session is still open, the message is piped to a temp file which
> is then scanned for spam, if it passes the temp file is piped to my

Both of these sound like redirection, not piping.

>>(I don't see what you mean by `a pipe rom /proc/kmsg', though:
>>pipes connect processes, not files. File redirections are
>>quite different and should work unchanged in 2.6.11.)
> 
> An interesting technique that allows a program (such as a log writer)
> to run as an unprivileged user, while receiving privileged data. (taken
> almost verbatim from Gerrit Pape's socklog)
> 
> #!/bin/sh
> exec  exec 2>&1
> exec softlimit -m 200 setuidgid nobody socklog ucspi
> 
> This script, run by root takes its stdin from /proc/kmsg then combines
> its stdout and stderr, and exec-switches to the socklog program run
> as an ucspi application listening to the domain stream socket, as
> nobody:nogroup, with memory consumption limited to 2Mb. (and sends
> log to stdout)

This is definitely redirection, not piping. As far as I know the
implementation of redirection in the kernel remains unchanged: certainly
the need to buffer piped data doesn't exist in this case, and since the
redesign was of the buffering, this is probably not your problem :)

> It worked flawlessly until several kernel revs back when the kernel
> started protecting kmsg and wouldn't allow the user program to receive
> it,

Indeed.

>   result: nothing sent to the logging program and no error. The fix
> was to run socklog as root instead of nobody.

You should be able to open it as root and read from it as another user:
i.e., your technique above shouldn't break. (I'd hope.)

-- 
> ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-09 Thread Nix 
On Tue, 8 Mar 2005, George Georgalis announced authoritatively:
 Here's what I'm doing that is broken. I use tcpserver (functionally
 similar to inetd) to receive an incoming smtp connection. While the
 smtp session is still open, the message is piped to a temp file which
 is then scanned for spam, if it passes the temp file is piped to my

Both of these sound like redirection, not piping.

(I don't see what you mean by `a pipe rom /proc/kmsg', though:
pipes connect processes, not files. File redirections are
quite different and should work unchanged in 2.6.11.)
 
 An interesting technique that allows a program (such as a log writer)
 to run as an unprivileged user, while receiving privileged data. (taken
 almost verbatim from Gerrit Pape's socklog)
 
 #!/bin/sh
 exec /proc/kmsg
 exec 21
 exec softlimit -m 200 setuidgid nobody socklog ucspi
 
 This script, run by root takes its stdin from /proc/kmsg then combines
 its stdout and stderr, and exec-switches to the socklog program run
 as an ucspi application listening to the domain stream socket, as
 nobody:nogroup, with memory consumption limited to 2Mb. (and sends
 log to stdout)

This is definitely redirection, not piping. As far as I know the
implementation of redirection in the kernel remains unchanged: certainly
the need to buffer piped data doesn't exist in this case, and since the
redesign was of the buffering, this is probably not your problem :)

 It worked flawlessly until several kernel revs back when the kernel
 started protecting kmsg and wouldn't allow the user program to receive
 it,

Indeed.

   result: nothing sent to the logging program and no error. The fix
 was to run socklog as root instead of nobody.

You should be able to open it as root and read from it as another user:
i.e., your technique above shouldn't break. (I'd hope.)

-- 
 ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-09 Thread George Georgalis 
On Wed, Mar 09, 2005 at 01:06:11PM +, Nix wrote:

 An interesting technique that allows a program (such as a log writer)
 to run as an unprivileged user, while receiving privileged data. (taken
 almost verbatim from Gerrit Pape's socklog)
 
 #!/bin/sh
 exec /proc/kmsg
 exec 21
 exec softlimit -m 200 setuidgid nobody socklog ucspi
 
 This script, run by root takes its stdin from /proc/kmsg then combines
 its stdout and stderr, and exec-switches to the socklog program run
 as an ucspi application listening to the domain stream socket, as
 nobody:nogroup, with memory consumption limited to 2Mb. (and sends
 log to stdout)

This is definitely redirection, not piping. As far as I know the
implementation of redirection in the kernel remains unchanged: certainly
the need to buffer piped data doesn't exist in this case, and since the
redesign was of the buffering, this is probably not your problem :)

 It worked flawlessly until several kernel revs back when the kernel
 started protecting kmsg and wouldn't allow the user program to receive
 it,

Indeed.

   result: nothing sent to the logging program and no error. The fix
 was to run socklog as root instead of nobody.

You should be able to open it as root and read from it as another user:
i.e., your technique above shouldn't break. (I'd hope.)

Here is a nice proof that kmsg did become a problem around 2.6.0
http://article.gmane.org/gmane.comp.misc.pape.general/595
http://thread.gmane.org/gmane.comp.misc.pape.general/590


It (Gerrit Pape's technique) very defiantly stopped working a few revs
back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
mplayer with 2.6.10, now too.

http://lkml.org/lkml/2005/3/8/226

while read file; do mplayer $file ; done mediafiles.txt

Failed to open /dev/rtc: Permission denied

for file in `cat mediafiles.txt`; do mplayer $file ; done

works.

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-09 Thread Paul Jarc 
George Georgalis [EMAIL PROTECTED] wrote:
 It (Gerrit Pape's technique) very defiantly stopped working a few revs
 back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
 mplayer with 2.6.10, now too.

The /proc/kmsg problem happens because the kernel now checks for
permission at read() instead of open().  The /dev/rtc problem seems to
be a different beast.

 while read file; do mplayer $file ; done mediafiles.txt

 Failed to open /dev/rtc: Permission denied

 for file in `cat mediafiles.txt`; do mplayer $file ; done

 works.

To simplify, what about these two:
mplayer foo.mpg
mplayer foo.mpg  mediafiles.txt

You might try strace'ing both cases and see how they compare.


paul
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-09 Thread Nix 
On Wed, 09 Mar 2005, Paul Jarc uttered the following:
 George Georgalis [EMAIL PROTECTED] wrote:
 It (Gerrit Pape's technique) very defiantly stopped working a few revs
 back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
 mplayer with 2.6.10, now too.
 
 The /proc/kmsg problem happens because the kernel now checks for
 permission at read() instead of open().

Am I the only person who thinks `eee-ick, how utterly non-POSIX' at
that?

-- 
 ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-08 Thread Andre Tomt 
George Georgalis wrote:
Here is a problem with 2.6.10:
while read file; do mplayer $file ; done 
or
tail -n93  mediafiles.txt | while read file; do mplayer $file ; done
for each file path in that text file I get:
Failed to open /dev/rtc: Permission denied (it should be readable by the user.)
^- This is also emitted by mplayer. It usually does this on any standard 
system.

In addition the audio pcm level is set to zero (presumably by mplayer).
This does work:
for file in `cat mediafiles.txt`; do mplayer $file ; done
but discovering and fixing code now broke will be unpleasent.
What exactly is going on? 

// George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-08 Thread George Georgalis 
On Tue, 8 Mar 2005 12:19:53 -0500, George Georgalis <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 08, 2005 at 11:58:14AM -0500, George Georgalis wrote:
> >On Tue, Mar 08, 2005 at 01:37:03PM +, Nix wrote:
> >>On Thu, 3 Mar 2005, George Georgalis uttered the following:
> >>> I recall a problem a while back with a pipe from
> >>> /proc/kmsg that was sent by root to a program with a
> >>> user uid. The fix was to run the logging program as
> >>> root. Has that protected pipe method been extended
> >>> since 2.6.8.1?
> >>
> >>The entire implementation of pipes has been radically revised between
> >>2.6.10 and 2.6.11: see, e.g.,  and
> >>.
> >>
> >>Bugs have been spotted in this area in 2.6.10: this may be
> >>another one.
> >
> >Thanks, my issue is clearly between 2.6.10 and 2.6.11; though I won't be
> >able to drill down anything more specific, for a while. The links
> >do look relevant but I cannot say for sure.

Here is a problem with 2.6.10:

while read file; do mplayer $file ; done http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-08 Thread George Georgalis 
On Tue, Mar 08, 2005 at 11:58:14AM -0500, George Georgalis wrote:
>On Tue, Mar 08, 2005 at 01:37:03PM +, Nix wrote:
>>On Thu, 3 Mar 2005, George Georgalis uttered the following:
>>> I recall a problem a while back with a pipe from
>>> /proc/kmsg that was sent by root to a program with a
>>> user uid. The fix was to run the logging program as
>>> root. Has that protected pipe method been extended
>>> since 2.6.8.1?
>>
>>The entire implementation of pipes has been radically revised between
>>2.6.10 and 2.6.11: see, e.g.,  and
>>.
>>
>>Bugs have been spotted in this area in 2.6.10: this may be
>>another one.
>
>Thanks, my issue is clearly between 2.6.10 and 2.6.11; though I won't be
>able to drill down anything more specific, for a while. The links
>do look relevant but I cannot say for sure.

My last post didn't actually describe what the problem is, which is
spamassassin always scores 0/0 under 2.6.11 but functions properly
(scoring x/5) under 2.6.10.

More details are in the thread of this post.
http://lkml.org/lkml/2005/3/3/513

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-08 Thread George Georgalis 
On Tue, Mar 08, 2005 at 01:37:03PM +, Nix wrote:
>On Thu, 3 Mar 2005, George Georgalis uttered the following:
>> I recall a problem a while back with a pipe from
>> /proc/kmsg that was sent by root to a program with a
>> user uid. The fix was to run the logging program as
>> root. Has that protected pipe method been extended
>> since 2.6.8.1?
>
>The entire implementation of pipes has been radically revised between
>2.6.10 and 2.6.11: see, e.g., <http://lwn.net/Articles/118750/> and
><http://lwn.net/Articles/119682/>.
>
>Bugs have been spotted in this area in 2.6.10: this may be
>another one.

Thanks, my issue is clearly between 2.6.10 and 2.6.11; though I won't be
able to drill down anything more specific, for a while. The links
do look relevant but I cannot say for sure.

Here's what I'm doing that is broken. I use tcpserver (functionally
similar to inetd) to receive an incoming smtp connection. While the
smtp session is still open, the message is piped to a temp file which
is then scanned for spam, if it passes the temp file is piped to my
local delivery program. If it doesn't pass the spam test or the delivery
program fails (disk full etc), the respective error code, if any,
is passed to tcpserver. The corresponding accepted, temporary reject or
permanently reject signal is passed to the remote sender.

The temp file is then removed or, for spam, it is cataloged for
statistics and/or abuse reporting. An additional copy is kept in a
traditional maildir to check for false positives.

#!/bin/bash
# exit 31 = permanently refuse
# exit 71 = temporarily refuse
# pwd is /var/qmail
echo $0 # for the logs
scq="spamc-queue" # a maildir with qmaild write perms
tmp="${scq}/`safecat "${scq}/tmp" "${scq}" >$sipd/date # keep track of when they 
came
maildir "${sipd}" >/dev/null <"$tmp" # keep a copy for reporting
maildir "${scq}"  >/dev/null <"$tmp" # save it to verify no falseys
rm "$tmp"
exit 31
;;
*) # spamc error, 
echo "$0 error, spamc exit $sce"
exit 71
esac
exit 81 # Internal bug



>If you can reproduce it consistently, *please* report
>this to the linux-kernel list!

I did, but have had no response to my followup:

Date: Fri, 4 Mar 2005 15:58:43 -0500
Subject: Re: problem with linux 2.6.11 and sa


>(I don't see what you mean by `a pipe rom /proc/kmsg', though:
>pipes connect processes, not files. File redirections are
>quite different and should work unchanged in 2.6.11.)


An interesting technique that allows a program (such as a log writer)
to run as an unprivileged user, while receiving privileged data. (taken
almost verbatim from Gerrit Pape's socklog)

#!/bin/sh
exec &1
exec softlimit -m 200 setuidgid nobody socklog ucspi

This script, run by root takes its stdin from /proc/kmsg then combines
its stdout and stderr, and exec-switches to the socklog program run
as an ucspi application listening to the domain stream socket, as
nobody:nogroup, with memory consumption limited to 2Mb. (and sends
log to stdout)

It worked flawlessly until several kernel revs back when the kernel
started protecting kmsg and wouldn't allow the user program to receive
it, result: nothing sent to the logging program and no error. The fix
was to run socklog as root instead of nobody.

// George



-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-08 Thread George Georgalis 
On Tue, Mar 08, 2005 at 01:37:03PM +, Nix wrote:
On Thu, 3 Mar 2005, George Georgalis uttered the following:
 I recall a problem a while back with a pipe from
 /proc/kmsg that was sent by root to a program with a
 user uid. The fix was to run the logging program as
 root. Has that protected pipe method been extended
 since 2.6.8.1?

The entire implementation of pipes has been radically revised between
2.6.10 and 2.6.11: see, e.g., http://lwn.net/Articles/118750/ and
http://lwn.net/Articles/119682/.

Bugs have been spotted in this area in 2.6.10: this may be
another one.

Thanks, my issue is clearly between 2.6.10 and 2.6.11; though I won't be
able to drill down anything more specific, for a while. The links
do look relevant but I cannot say for sure.

Here's what I'm doing that is broken. I use tcpserver (functionally
similar to inetd) to receive an incoming smtp connection. While the
smtp session is still open, the message is piped to a temp file which
is then scanned for spam, if it passes the temp file is piped to my
local delivery program. If it doesn't pass the spam test or the delivery
program fails (disk full etc), the respective error code, if any,
is passed to tcpserver. The corresponding accepted, temporary reject or
permanently reject signal is passed to the remote sender.

The temp file is then removed or, for spam, it is cataloged for
statistics and/or abuse reporting. An additional copy is kept in a
traditional maildir to check for false positives.

#!/bin/bash
# exit 31 = permanently refuse
# exit 71 = temporarily refuse
# pwd is /var/qmail
echo $0 # for the logs
scq=spamc-queue # a maildir with qmaild write perms
tmp=${scq}/`safecat ${scq}/tmp ${scq} /dev/stdin` \
|| { echo Error $?; exit 71; } # put the pipeline to disk, if possible
# ${scq}/tmp is a temp for this function ${scq} is temp for this program
score=`spamc -x -c $tmp` # score it with spamd
sce=$?
echo $score # for the logs
case $sce in
0) # ham
host=`cat control/me`
formail -f -A X-spamc: ${score} by ${host}; `date -R` \
-A X-tcpremoteip: $TCPREMOTEIP $tmp \
| bin/qmail-queue # mark it and pass to the regular queue
qqe=$?
rm $tmp
exit $qqe # return whatever qmail-queue exits as
;;
1) # spam 
sipd=$scq/IP/`echo $TCPREMOTEIP | sed 's|\.|/|g'`
mkdir -p $sipd/{new,cur,tmp} # make a spam ip maildir, if needed
printf $TCPREMOTEIP\t`date`\n $sipd/date # keep track of when they 
came
maildir ${sipd} /dev/null $tmp # keep a copy for reporting
maildir ${scq}  /dev/null $tmp # save it to verify no falseys
rm $tmp
exit 31
;;
*) # spamc error, 
echo $0 error, spamc exit $sce
exit 71
esac
exit 81 # Internal bug



If you can reproduce it consistently, *please* report
this to the linux-kernel list!

I did, but have had no response to my followup:

Date: Fri, 4 Mar 2005 15:58:43 -0500
Subject: Re: problem with linux 2.6.11 and sa


(I don't see what you mean by `a pipe rom /proc/kmsg', though:
pipes connect processes, not files. File redirections are
quite different and should work unchanged in 2.6.11.)


An interesting technique that allows a program (such as a log writer)
to run as an unprivileged user, while receiving privileged data. (taken
almost verbatim from Gerrit Pape's socklog)

#!/bin/sh
exec /proc/kmsg
exec 21
exec softlimit -m 200 setuidgid nobody socklog ucspi

This script, run by root takes its stdin from /proc/kmsg then combines
its stdout and stderr, and exec-switches to the socklog program run
as an ucspi application listening to the domain stream socket, as
nobody:nogroup, with memory consumption limited to 2Mb. (and sends
log to stdout)

It worked flawlessly until several kernel revs back when the kernel
started protecting kmsg and wouldn't allow the user program to receive
it, result: nothing sent to the logging program and no error. The fix
was to run socklog as root instead of nobody.

// George



-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-08 Thread George Georgalis 
On Tue, Mar 08, 2005 at 11:58:14AM -0500, George Georgalis wrote:
On Tue, Mar 08, 2005 at 01:37:03PM +, Nix wrote:
On Thu, 3 Mar 2005, George Georgalis uttered the following:
 I recall a problem a while back with a pipe from
 /proc/kmsg that was sent by root to a program with a
 user uid. The fix was to run the logging program as
 root. Has that protected pipe method been extended
 since 2.6.8.1?

The entire implementation of pipes has been radically revised between
2.6.10 and 2.6.11: see, e.g., http://lwn.net/Articles/118750/ and
http://lwn.net/Articles/119682/.

Bugs have been spotted in this area in 2.6.10: this may be
another one.

Thanks, my issue is clearly between 2.6.10 and 2.6.11; though I won't be
able to drill down anything more specific, for a while. The links
do look relevant but I cannot say for sure.

My last post didn't actually describe what the problem is, which is
spamassassin always scores 0/0 under 2.6.11 but functions properly
(scoring x/5) under 2.6.10.

More details are in the thread of this post.
http://lkml.org/lkml/2005/3/3/513

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-08 Thread George Georgalis 
On Tue, 8 Mar 2005 12:19:53 -0500, George Georgalis [EMAIL PROTECTED] wrote:
 On Tue, Mar 08, 2005 at 11:58:14AM -0500, George Georgalis wrote:
 On Tue, Mar 08, 2005 at 01:37:03PM +, Nix wrote:
 On Thu, 3 Mar 2005, George Georgalis uttered the following:
  I recall a problem a while back with a pipe from
  /proc/kmsg that was sent by root to a program with a
  user uid. The fix was to run the logging program as
  root. Has that protected pipe method been extended
  since 2.6.8.1?
 
 The entire implementation of pipes has been radically revised between
 2.6.10 and 2.6.11: see, e.g., http://lwn.net/Articles/118750/ and
 http://lwn.net/Articles/119682/.
 
 Bugs have been spotted in this area in 2.6.10: this may be
 another one.
 
 Thanks, my issue is clearly between 2.6.10 and 2.6.11; though I won't be
 able to drill down anything more specific, for a while. The links
 do look relevant but I cannot say for sure.

Here is a problem with 2.6.10:

while read file; do mplayer $file ; done mediafiles.txt

or

tail -n93  mediafiles.txt | while read file; do mplayer $file ; done

for each file path in that text file I get:

Failed to open /dev/rtc: Permission denied (it should be readable by the user.)

In addition the audio pcm level is set to zero (presumably by mplayer).

This does work:
for file in `cat mediafiles.txt`; do mplayer $file ; done

but discovering and fixing code now broke will be unpleasent.
What exactly is going on? 

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a problem with linux 2.6.11 and sa

2005-03-08 Thread Andre Tomt 
George Georgalis wrote:
Here is a problem with 2.6.10:
while read file; do mplayer $file ; done mediafiles.txt
or
tail -n93  mediafiles.txt | while read file; do mplayer $file ; done
for each file path in that text file I get:
Failed to open /dev/rtc: Permission denied (it should be readable by the user.)
^- This is also emitted by mplayer. It usually does this on any standard 
system.

In addition the audio pcm level is set to zero (presumably by mplayer).
This does work:
for file in `cat mediafiles.txt`; do mplayer $file ; done
but discovering and fixing code now broke will be unpleasent.
What exactly is going on? 

// George
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with linux 2.6.11 and sa

2005-03-04 Thread George Georgalis 
On Fri, 4 Mar 2005 13:53:50 -0500, George Georgalis <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Mar 2005 23:37:06 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 03, 2005 at 01:57:28PM -0500, George Georgalis wrote:
> > > I recall a problem a while back with a pipe from
> > > /proc/kmsg that was sent by root to a program with a
> > > user uid. The fix was to run the logging program as
> > > root. Has that protected pipe method been extended
> > > since 2.6.8.1?
> > >
> > > I'm very defiantly seeing a problem with the 2.6.11
> > > kernel and my spamassassin setup. However, it's not
> > > clear exactly where the problem is, seems like sa
> > > but it might be 2.6.11 with daemontools + qmail +
> > > QMAIL_QUEUE.
> >
> > Does reverting to 2.6.10 fix this behavior?
> 
> Yes, actually I revert to 2.6.8.1; will try 2.6.10 today...

I did make oldconfig (n,n,n) with my 2.6.11 .config
and seems to be working normal. Could
CONFIG_PREEMPT_BKL=y
have anything to do with it?

http://galis.org/linux-2.6.11-sta.config
http://galis.org/linux-2.6.10-sta.conf

// George
-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with linux 2.6.11 and sa

2005-03-04 Thread George Georgalis 
On Thu, 3 Mar 2005 23:37:06 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 03, 2005 at 01:57:28PM -0500, George Georgalis wrote:
> > I recall a problem a while back with a pipe from
> > /proc/kmsg that was sent by root to a program with a
> > user uid. The fix was to run the logging program as
> > root. Has that protected pipe method been extended
> > since 2.6.8.1?
> >
> > I'm very defiantly seeing a problem with the 2.6.11
> > kernel and my spamassassin setup. However, it's not
> > clear exactly where the problem is, seems like sa
> > but it might be 2.6.11 with daemontools + qmail +
> > QMAIL_QUEUE.
> 
> Does reverting to 2.6.10 fix this behavior?

Yes, actually I revert to 2.6.8.1; will try 2.6.10 today...

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with linux 2.6.11 and sa

2005-03-04 Thread George Georgalis 
On Thu, 3 Mar 2005 23:37:06 -0500, Jeff Garzik [EMAIL PROTECTED] wrote:
 On Thu, Mar 03, 2005 at 01:57:28PM -0500, George Georgalis wrote:
  I recall a problem a while back with a pipe from
  /proc/kmsg that was sent by root to a program with a
  user uid. The fix was to run the logging program as
  root. Has that protected pipe method been extended
  since 2.6.8.1?
 
  I'm very defiantly seeing a problem with the 2.6.11
  kernel and my spamassassin setup. However, it's not
  clear exactly where the problem is, seems like sa
  but it might be 2.6.11 with daemontools + qmail +
  QMAIL_QUEUE.
 
 Does reverting to 2.6.10 fix this behavior?

Yes, actually I revert to 2.6.8.1; will try 2.6.10 today...

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with linux 2.6.11 and sa

2005-03-04 Thread George Georgalis 
On Fri, 4 Mar 2005 13:53:50 -0500, George Georgalis [EMAIL PROTECTED] wrote:
 On Thu, 3 Mar 2005 23:37:06 -0500, Jeff Garzik [EMAIL PROTECTED] wrote:
  On Thu, Mar 03, 2005 at 01:57:28PM -0500, George Georgalis wrote:
   I recall a problem a while back with a pipe from
   /proc/kmsg that was sent by root to a program with a
   user uid. The fix was to run the logging program as
   root. Has that protected pipe method been extended
   since 2.6.8.1?
  
   I'm very defiantly seeing a problem with the 2.6.11
   kernel and my spamassassin setup. However, it's not
   clear exactly where the problem is, seems like sa
   but it might be 2.6.11 with daemontools + qmail +
   QMAIL_QUEUE.
 
  Does reverting to 2.6.10 fix this behavior?
 
 Yes, actually I revert to 2.6.8.1; will try 2.6.10 today...

I did make oldconfig (n,n,n) with my 2.6.11 .config
and seems to be working normal. Could
CONFIG_PREEMPT_BKL=y
have anything to do with it?

http://galis.org/linux-2.6.11-sta.config
http://galis.org/linux-2.6.10-sta.conf

// George
-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with linux 2.6.11 and sa

2005-03-03 Thread Jeff Garzik 
On Thu, Mar 03, 2005 at 01:57:28PM -0500, George Georgalis wrote:
> I recall a problem a while back with a pipe from
> /proc/kmsg that was sent by root to a program with a
> user uid. The fix was to run the logging program as
> root. Has that protected pipe method been extended
> since 2.6.8.1?
> 
> I'm very defiantly seeing a problem with the 2.6.11
> kernel and my spamassassin setup. However, it's not
> clear exactly where the problem is, seems like sa
> but it might be 2.6.11 with daemontools + qmail +
> QMAIL_QUEUE.

Does reverting to 2.6.10 fix this behavior?

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

problem with linux 2.6.11 and sa

2005-03-03 Thread George Georgalis 
I recall a problem a while back with a pipe from
/proc/kmsg that was sent by root to a program with a
user uid. The fix was to run the logging program as
root. Has that protected pipe method been extended
since 2.6.8.1?

I'm very defiantly seeing a problem with the 2.6.11
kernel and my spamassassin setup. However, it's not
clear exactly where the problem is, seems like sa
but it might be 2.6.11 with daemontools + qmail +
QMAIL_QUEUE.

A sure sign of it is no logs (with debug) for
remote sa connections which score "0/0" and correct
operation with local "cat spam.txt | spamc -R"; fix
is to use the older kernel.

SA has stopped stdout logging completely with 2.6.11
in addition to the all pass score. But the message
seems to go through my temp queue (for testing) and
sent on to my local MDA. I'm not sure if it's a sa
problem with the kernel or the new kernel doing
something new with pipes from tcp connections.
Maybe the new kernel is not making files available
(eg 0 bytes), until the writing pipe is closed?
That would make my SA test a zero byte file, which
would pass, close, become full, and the file piped
to local MDA is full? ...humm then I'd get a score
of "0/5"... this sounds like a SA problem with the
new kernel, ideas?

// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

problem with linux 2.6.11 and sa

2005-03-03 Thread George Georgalis 
Please keep me in cc as I'm not presently subscribed to lkml)

I recall a problem a while back with a pipe from
/proc/kmsg that was sent by root to a program with a
user uid. The fix was to run the logging program as
root. Has that protected pipe method been extended
since 2.6.8.1?


I'm very defiantly seeing a problem with the 2.6.11
kernel and my spamassassin setup. However, it's not
clear exactly where the problem is, seems like sa
but it might be 2.6.11 with daemontools + qmail +
QMAIL_QUEUE.

A sure sign of it is no logs (with debug) for
remote sa connections which score "0/0" and correct
operation with local "cat spam.txt | spamc -R"; fix
is to use the older kernel.

SA has stopped stdout logging completely with 2.6.11
in addition to the all pass score. But the message
seems to go through my temp queue (for testing) and
sent on to my local MDA. I'm not sure if it's a sa
problem with the kernel or the new kernel doing
something new with pipes from tcp connections.
Maybe the new kernel is not making files available
(eg 0 bytes), until the writing pipe is closed?
That would make my SA test a zero byte file, which
would pass, close, become full, and the file piped
to local MDA is full? ...humm then I'd get a score
of "0/5"... this sounds like a SA problem with the
new kernel, ideas?


// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

problem with linux 2.6.11 and sa

2005-03-03 Thread George Georgalis 
Please keep me in cc as I'm not presently subscribed to lkml)

I recall a problem a while back with a pipe from
/proc/kmsg that was sent by root to a program with a
user uid. The fix was to run the logging program as
root. Has that protected pipe method been extended
since 2.6.8.1?


I'm very defiantly seeing a problem with the 2.6.11
kernel and my spamassassin setup. However, it's not
clear exactly where the problem is, seems like sa
but it might be 2.6.11 with daemontools + qmail +
QMAIL_QUEUE.

A sure sign of it is no logs (with debug) for
remote sa connections which score 0/0 and correct
operation with local cat spam.txt | spamc -R; fix
is to use the older kernel.

SA has stopped stdout logging completely with 2.6.11
in addition to the all pass score. But the message
seems to go through my temp queue (for testing) and
sent on to my local MDA. I'm not sure if it's a sa
problem with the kernel or the new kernel doing
something new with pipes from tcp connections.
Maybe the new kernel is not making files available
(eg 0 bytes), until the writing pipe is closed?
That would make my SA test a zero byte file, which
would pass, close, become full, and the file piped
to local MDA is full? ...humm then I'd get a score
of 0/5... this sounds like a SA problem with the
new kernel, ideas?


// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/