| Summary: | app-admin/sysklogd - no way to disable startup of klogd when sysklogd is used in a vserver | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | R. David Murray <rdmurray> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | monsieurp |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge --info from vserver instance | ||
|
Description
R. David Murray
2011-05-27 01:52:08 UTC
Ah, when I said "no way", I meant from /etc/conf.d/sysklogd. Obviously I edited the init script directly to get my vserver instance to boot. That must be because it has "provide logger" and because something else has "need logger" or similar. Oh, and please post your `emerge --info' output too. No, the issue that sysklogd has two deamons: the regular logger, and the kernel logger. On a vserver, the kernel logger fails. It used to be that that was fine, it just failed, and initialization continued with only the regular deamon running. Now, however, initialization hangs when the kernel logger fails to start. What is needed is a change to the /etc/init.d/sysklogd script so that it will accept a variable in /etc/conf.d/sysklogd that controls whether or not an attempt to start the kernel logger is even made. The regular logger should continue to be influenced by requires/provides as it is now. I'll attach my emerge --info but only so you can see which version I'm on where startup hangs. Created attachment 275417 [details]
emerge --info from vserver instance
I haven't been able to reproduce this issue. I use sysklogd in a vserver guest and unless I specifically add it manually to the boot sequence with rc-update, it doesn't start automatically. Please reopen and give us with more info. |
