Bugzilla Bug 177424

Metalog v 0.8-rc4 was popped in as an emerge --sync, etc upgrade on 2006.1. The
prior sample and conf refered to the shell script "consolelog.sh" as being in
/usr/sbin/ and this worked fine. The ...-rc4 idem ditto, but it put the script
in /usr/bin. This error occurs on both x86 and x86_64 (AMD Turion) hardware. It
prevents boot from completing, the appearance of any kernel or other log
messages either in the log or on the virtual console (tty12, for me) and
X-server is unusable. Also dmesg | less shows wtmp contents instead of kernel
ring-buffer. I am very surprised this is not already a known issue and also for
the for me inexplicable move - I see logging as a "system" task, not an
(ordinary) user one.

Reproducible: Always

Steps to Reproduce:
1. Install metalog prior to Version 0.8-rc4 and taylor the conf including log
to (virtual) console - ie: uncomment.
2. Upgrade to 0.8-rc4, but do not change the log to (virtual) cons line(s).
3. Re-boot !

Actual Results:  
As in "Steps to Reproduce".

Expected Results:  
Console log on (Virtual) console, log file(s) and ability to log on to system.
Also, with Interactive or Single boot, dmesg | less should show the log from
the kernel ring buffer not the contents of wtmp - log-on/-off(s) history.

The change in "style" of the sample "metalog.conf" is irrelevant to this
problem - only the unexpected/undocumented move of the script. What is
happenning is that that vfs buffer pool is filled with log messages and causes
the system logger to abnormally terminate with a very high code - 127 I
believe.

Resolution is simple: just remove the "s" form
/usr/bin/consolelog.sh/usr/sbin/consolelog.sh in /etc/metalog.conf.

emerge --info is irrelevant to this problem - and now lost due to the upgrade
activities.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-admin/metalog/metalog-0.8_rc1-r2.ebuild?r1=1.14&r2=1.15

All ebuilds in the tree install this into /usr/bin because exeinto has no
effect on dobin.

<snip>
exeinto /usr/sbin
dobin "${FILESDIR}"/consolelog.sh || die
</snip>

i should update metalog so that it doesnt hang when a command doesnt exist ...

(In reply to comment #2)
> All ebuilds in the tree install this into /usr/bin because exeinto has no
> effect on dobin.

In which case, how about the same for the sample metalog.conf file contents.
The difference had me running around for a month. After which I decided I would
be better off using somebody else's Distro!

(In reply to comment #3)
> i should update metalog so that it doesnt hang when a command doesnt exist ...
> 
I agree that is the long-term solution. The PTF is as originally stated and
noted in Comment # 2 - My reply.

Personally, I would have done that as pretty well the first thing in the
development of the product.

Having said which, It is a fantastic, great, etc version of the System-Logger
Service. Thanks.

I just got bitten by this problem today, and it had me scratching my head as I
enabled the console logger on the same boot cycle as a bunch of other system
changes. In my case the major symptom was that the terminal login program would
stall after entering a password.

If I hadn't seen this thread I would've switched to another system logger and
not looked back. As it's an exceedingly simple problem and this bug is marked
New, I take it that just means no dev has seen this bug yet. What needs to
happen to change that?

*** Bug 184748 has been marked as a duplicate of this bug. ***

(In reply to comment #3)
> i should update metalog so that it doesnt hang when a command doesnt exist ...

That's nice, feel free to work on it once you've fixed the broken ebuilds.
Thanks. 

(In reply to comment #6)

> If I hadn't seen this thread I would've switched to another system logger and
> not looked back. As it's an exceedingly simple problem and this bug is marked
> New, I take it that just means no dev has seen this bug yet. What needs to
> happen to change that?
> 

That would be my question as well, considering this bug has existed for 2
months, and has the potential (as in my case) to prevent a server from even
coming up to the point where you can log in, even from a console.

At the very least, 0.8_rc4 and 0.8 ebuilds should be masked so that x86 and
x86_64 platforms don't get wounded by it.

I would be delighted to volunteer my time, except I haven't got the foggiest
idea how to manage an e-build.

I'm posting a diff here since the maintainer is clearly more concerned about
this bug keywords than about fixing the trivial issues in clearly broken
ebuild. Why does this take two months to fix one line in ebuild that causes
severe borkage to users, goes beyond me.

<snip>
--- metalog-0.8.ebuild  2007-06-21 09:05:34.000000000 +0200
+++ metalog-0.8.ebuild  2007-07-10 08:35:00.000000000 +0200
@@ -30,7 +30,7 @@
        newconfd "${FILESDIR}"/metalog.confd metalog

        exeinto /usr/sbin
-       dobin "${FILESDIR}"/consolelog.sh || die
+       doexe "${FILESDIR}"/consolelog.sh || die
 }

 pkg_preinst() {
</snip>

perhaps you should learn to stop being a jackass and maybe people would
actually listen to you

(In reply to comment #11)
> perhaps you should learn to stop being a jackass

Perhaps you could just fix the bug, which would take less time than what you've
actually spent on pointless comments like the one above and on useless messing
with this bug's keywords? If you don't want to, that's what the QAcanfix
keyword is for - unless you assume that QA in unable to properly change one
line in the ebuild so that it actually does what's intended and what it fails
to do due to an obvious mistake.

if you want to piss and moan, go somewhere else

i'd rather have a completely broken system than read another comment from you

Pim: i'm pretty sure i already fixed the hang issue if the thing specified by
command fails ... can you double check with metalog-0.8 ?

(In reply to comment #14)
> Pim: i'm pretty sure i already fixed the hang issue if the thing specified by
> command fails ... can you double check with metalog-0.8 ?
> 

Both 0.8_rc4 and 0.8 are bugged.  0.8 is the version that took my system down. 
Once I got it back up, I downgraded through 0.8_rc4 before settling on
0.8_rc1-r2 as the version that didn't kill my system.  The other versions
simply hang, and hang any process that tries to write to syslog.

Hope that helps.

> "if you want to piss and moan, go somewhere else"

He's pissed because the default behavior of a non-masked package is to hang the
system when a sample configuration is uncommented, and this default behavior
has remained uncorrected, either with a fix to the metalog program itself or to
the ebuild, after the problem has been known for months, due to a perceived
lack of effort. Whether or not this perception is correct is irrelevant to his
being upset.

> "i'd rather have a completely broken system than read another comment from you"

That's all well and good for you, but I for one wouldn't mind listening to
someone piss and moan if it saved me the time I spent determining my logger of
all things was the reason my system wouldn't boot.

This is pretty much my only experience so far with the gentoo bug system or any
bug tracker, so I'm not quite sure what the specific responsibilities of a
maintainer are, or what the deal is with QAcanfix. But I would prefer that you
not make that kind of decision for the rest of us.

you arent familiar with Jakub ... this is his behavior regardless of the bug
and i'm tired of it ... so stick to the issue: metalog, and not the other crap

Chris: can you build metalog with debugging and no stripping and when metalog
hangs, attach to it with gdb and get some information ?  i know older versions
of metalog had problems in the signal handler with logging, but i fixed those
in 0.8 and i cant get metalog to hang on my systems anymore ...

(In reply to comment #17)
> Chris: can you build metalog with debugging and no stripping and when metalog
> hangs, attach to it with gdb and get some information ?  i know older versions
> of metalog had problems in the signal handler with logging, but i fixed those
> in 0.8 and i cant get metalog to hang on my systems anymore ...
> 

I've sent you an e-mail, though I'm afraid what I got isn't going to be very
useful to you.

SpanKY, were you able to make use of the info I sent you?  Is there anything
else I can do?

(In reply to comment #15)
> (In reply to comment #14)
> > Pim: i'm pretty sure i already fixed the hang issue if the thing specified by
> > command fails ... can you double check with metalog-0.8 ?
> > 
> 
> Both 0.8_rc4 and 0.8 are bugged.  0.8 is the version that took my system down. 
> Once I got it back up, I downgraded through 0.8_rc4 before settling on
> 0.8_rc1-r2 as the version that didn't kill my system.  The other versions
> simply hang, and hang any process that tries to write to syslog.
> 
> Hope that helps.
> 
Sorry to be so slow in coming back.

It does not really help as the "PTF", ie: the get you out a hole type fix is as
originally stated by me, does all that I need it to do at the moment. Perhaps I
was not explicit or clear enough? Either simply change the path of the "module"
(shell script) to point to where it actually was placed by the installation
process or move the "module" to where in my utter stupidity would believe to be
the "natural" place to put this type of "module" - ie "/usr/sbin/".

I stated in the original problem report that I had as a matter of course
upgraded to "0.8_rc4" and the release of the "base" that I then had in use.
Quite frankly I have simply no idea what is being requested of me here.

I have been subjected to an absolutely ginormous amount of being told that I am
"legacy", etc., etc. But the way I have always handled these issues at either
end of this very terrible stick is to 1) Report the actual cause of the problem
along with its symptons 2) Provide a "quick and dirty" way of circumventing -
that is avoiding for us normal bozos - the problem(s) and 3) either fix it
properly 'cos that is what I used to get paid mega-bucks to do by tiny and
entirely unknown labs/companies like IBM, GEC (US one) or pass it to some poor
sucker saddled with the doing the job for my client - for some reason they got
pretty narked at paying me mega-bucks to do what the supplier promised to do as
part of the supplier's fee. Very strange world - just can not get rich quick -
not no how not ever.

I would very strongly recommend to the developer(s) that they do their utmost
to keep the provided sample - even if commented out - in line with what the
poor old "legacy" berks like me get delivered at our end. Also I would add a
"dire warning" to the self same sample as to the consequences of getting it
wrong. This has effectively already been explicitly stated in other comments.

Slightly off-topic, but ... Almost any provider of "proprietry" software would
term this issue as "user error". 'Cos this is "Free" software and far more
obviously from the multifarious comments above and below, this and many other
issues are being taken seriously by amongst others the developer(s). For the
great joy of being permitted to take part in all this - my hartfelt thanks to
one and all.

*** Bug 185356 has been marked as a duplicate of this bug. ***

Summary is incorrect: metalog-0.8_rc1-r2 is the only version that works for me.
 ALL later versions (0.8_rc2, 0.8_rc4, 0.8, and 0.8-r1) hang my system.  To
make matters worse, the only ebuild in the system is 0.8-r1, meaning that if
some other poor sap gets nailed by this bug, he's going to have to go dig the
e-build for a previous version out of CVS in order to recover his system.

I am willing to help in whatever way my meager skills allow to solve this
problem, but whatever the issue is, it is NOT as simple as not being able to
find the command file, because the only command file I'm using is
consolelog.sh, and I have copied it into both /usr/sbin and /sbin, and I still
have the problem.

(In reply to comment #22)
> Summary is incorrect: metalog-0.8_rc1-r2 is the only version that works for me.

The summary is just fine, note the > in front.

Ah, So I see.  Thanks.

unable to reproduce with metalog-0.9

(In reply to comment #25)
> unable to reproduce with metalog-0.9
> 

I recompiled my system in late 2007 as part of a move to a new server, and
moved to a newer system profile ( /usr/portage/profiles/hardened/linux/x86). 
The net result is that I am currently running Metalog 0.8-rc1 without issues,
where previously it would kill my system.  It would thus appear that there was
something 'interesting' about my previous system configuration that was
interacting with metalog in some way to produce the issues I was having.  As
that system configuration no longer exists, there's no way to determine what
the problem was, or if the problem still exists.