danny@idacom.UUCP (Danny Wilson) (05/29/89)
We are running SR9.7 Aegis with Domain/IX (BSD4.2). Every once in a while I notice that the syslog process is consuming CPU time like crazy (up to 90% as reported by dspst). Both /bin/ps and /com/pst show that something is really happening there. Our /etc/syslog.conf contains '1*/dev/log', so trying to 'catf' /dev/log results in: Error: unable to open file "log" - system (or process) crash prevented complete file close. (or something like that...) Has anyone seen this before? How do I fix it? (Is it really worth running syslog at all?) The answers to these questions and more can (hopefully) be found... _on_the_network_. -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta alberta!idacom!danny C A N A D A
weber_w@apollo.COM (Walt Weber) (06/01/89)
In article <674@idacom.UUCP> danny@idacom.UUCP (Danny Wilson) writes: >Our /etc/syslog.conf contains '1*/dev/log', so trying to 'catf' >/dev/log results in: > > Error: unable to open file "log" - system (or process) crash > prevented complete file close. The extensible streams documentation (Open Systems Toolkit) discusses the 32-byte streams header which precedes user data on files of type 'uasc'. The message above indicates that the /dev/log file has a corrupted streams header. Change it's name so that you can create a new one, and syslogd will revert to it's normal, unobtrusive self... Note that /com/catf attempts to open a file using constraints of "nR_xor_1W", which is N-Readers eXclusive-OR 1-Writer. Since syslogd opens the file for writing via open(2) (which uses constraint Cowriters, or "ios_$unregulated"), your catf will fail. If you use /bin/cat (which also uses open(2)) you will be able to look at the file, PROVIDING you make the attempt from the same node which is holding the lock (read: node where syslog is running). ...walt... >Danny Wilson >IDACOM Electronics danny@idacom.uucp -- Walt Weber Apollo Division of the Hewlett-Packard Company (508) 256-6600 x8315 People's Republic of Massachusetts -The views expressed herein are personal, and not binding on ANYONE-
krowitz@RICHTER.MIT.EDU (David Krowitz) (06/02/89)
Talking about corrupted stream headers ... is their anyway to retrieve the contents of a file that has that error message (file not closed properly due to system crash ...)? Is there some way just to patch up the header of a UASC or REC file? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
mishkin@apollo.COM (Nathaniel Mishkin) (06/03/89)
In article <438f3c86.10b48@apollo.COM> weber_w@apollo.COM (Walt Weber) writes: >In article <674@idacom.UUCP> danny@idacom.UUCP (Danny Wilson) writes: >>Our /etc/syslog.conf contains '1*/dev/log', so trying to 'catf' >>/dev/log results in: >> >> Error: unable to open file "log" - system (or process) crash >> prevented complete file close. > >The extensible streams documentation (Open Systems Toolkit) discusses the >32-byte streams header which precedes user data on files of type 'uasc'. >The message above indicates that the /dev/log file has a corrupted >streams header. Change it's name so that you can create a new one, and >syslogd will revert to it's normal, unobtrusive self... Because this was always such a nuisance (and for other reasons) at sr10.x, the default type of file ("unstruct" or "nil") doesn't have a 32 byte header and hence you tend not to see this problem any more. -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com