Bug 23482

Summary:	System won't start without syslog
Product:	[Retired] Red Hat Raw Hide	Reporter:	Andrew Bartlett <abartlet>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED RAWHIDE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.0	CC:	rvokal
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-01-29 22:54:17 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andrew Bartlett 2001-01-06 12:16:26 UTC

Ok, so I decided to see what happened if I attempted to start the system
without syslog.  (Whats my muck-about machine for but to find this stuff
out!).  Anyway, contary to what I had expected from reading bug 22196 my
system got nowhere. 
It stopped when runing init.d/random, and would not shut down
(Ctrl-Alt-Del), as the ypbind script wouldn't run.  
I am assuming that it is the logging funcion of each of these scripts that
is blocking - but I am not sure why.  If minilogd is still running,
shouldn't it keep accepting the messages?  If minilogd is fixed not to chew
RAM, shouldn't it just start throwing away messages?

Anyway, I rebooted back into single user mode (1 fsck later) and restored
syslog to startup, and all is back to normal, but shouldn't the system
attempt to limp into service if at all possible?  (Or at least allow a
clean shutdown?)

Comment 1 Bill Nottingham 2001-01-29 22:54:13 UTC

minilogd is stuck waiting for portmap to say something.

Comment 2 Bill Nottingham 2001-01-29 23:24:00 UTC

A quick&dirty alarm handler will be in minilogd in initscripts-5.60-1,
that should prevent this deadlock. It's still not recommended to
run without syslogd running. :)

Comment 3 Doug Ledford 2001-02-21 23:56:47 UTC

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