Summary: | metalog random freezes that require restarting it | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | tuxisuau <tuxisuau> |
Component: | [OLD] GCC Porting | Assignee: | Matthew Kennedy (RETIRED) <mkennedy> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | sascha-gentoo-bugzilla |
Priority: | High | ||
Version: | 1.1a | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 8607 |
Description
tuxisuau
2002-06-05 23:26:46 UTC
This is not a bug. What you are seeing is the buffering nature of metalog. (see metalog(1)). You can turn the buffing off at runtime with SIGUSR1 and turn it back on with SIGUSR2. Matt This IS a bug. Buffering nature of metalog stands for writing the logs in the hard disk, not from accepting data from servers. 
It's serious enough it makes apps freeze, and yes, it gave the same problem with the buffering disabled.
Now i'm using syslog-ng.

Tuxisuau. If you use -march=i686 (instead of athlon) do you get the same problem? Never in several months that I have been using metalog w/ gcc3.0.4 and gcc3.1 have I see the behavior you describe. do you get a freeze at all with syslog-ng? I'm hitting the same bug. Occured during the gcc 2.95.x time and is still happening. Had buffering turned off (-s) and tried it with buffering this week, but it seems to only get worse if buffering is turned on (even happened immediatly after one of the reboots). See the comments on the other bug for details. As soon as it happens again, I'll attach gdb to metalog. Perhaps I can get more info that way. And please reopen the bug again, it does NOT work. PS: athlon-xp CPU |