non syslog activity...

[James Ellis_1]

I noticed the syslog.log file was not showing any activity since two days ago. Did a ps-ef | grep syslog and nothing comes up so I restarted the log file. However, there still was not any activity when I tried to ftp to the server. I checked the /etc/syslog.conf file and noticed everything was missing but the

*.info /usr/uni/opr/config/servername/oprpipe0130

I think I need to get the original configuration in there. Can I ftp it from another HP server to this HP server?

Not sure how it got corrupted, but unicenter was restarted at the time and the syslog file shows uni logging activity stoped at the time uni was shutting down.

Anyway, I wanted to know if it is ok to ftp the syslog.conf from another server to this server, and then restart the syslogd?

Thanks.

[Pete Randall]

James,

I would say it should be fine to copy it from another server. The only exception would be if you had previously done any customizing of it. The ideal solution would be to restore from backup but any way you can get it back is what matters.


Pete

[Pete Randall]

James,

Oh - and you'll probably need to restart the syslogd.


Pete

[Pete Randall]

James,

To make syslogd, re-read its configuration file, send it a HANGUP
signal:

kill -HUP `cat /var/run/syslog.pid`

Pete

[Marco Santerre]

I think that ftp'ing from another server should be fine. The only question I would have is "How did that config got changed?" But, the first thing I would do is definitely fix it. Then find out what happened.

[Dave Hutton]

Like Pete said, I wouldn't think it would be a problem. There should be an original file at:
/usr/newconfig/etc/syslog.conf
That you could stick in the place. We've looked at customizing ours to funnel a few routers syslog type messages to a server so we can monitor with ITO/NNM.

[James Ellis_1]

Pete,

I don't think there was any customizations done because we got two identical servers and they should be configured the same as much as possible. The only difference I can see is the last line showing:

/usr/uni/opr/config/server1/pipe/oprpipe0001
(from the problem server)

to

/usr/uni/opr/config/server2/pipe/oprpipe0130
(good working server)

What does the last digits of these two lines mean? Should I preserve the last digits from the problem server?

Thanks.

[James Ellis_1]

Marco,

Here is a post of the last portion of syslog:
-------------------------------
Jan 5 10:03:40 hserv syslog: .SCTY_E_999 Evaluator PID #20292;

exiting for restart.

Jan 5 10:03:40 hserv syslog: .SCTY_I_999 Evaluator PID #20290;

normal shutdown.

Jan 5 10:03:40 hserv syslog: .SCTY_I_999 Evaluator PID #20291;

normal shutdown.

Jan 5 10:03:40 hserv vmunix: CAIENF_S_0181 10:03:40.267 SSF

shutdown successful

Jan 5 10:03:40 hserv username: unishutdown: attempting to shut down

Unicenter TNG 'star' component...

Jan 5 10:03:42 hserv username: unishutdown: attempting to shut down

Unicenter TNG 'emsrvc' component...

Jan 5 10:03:58 hserv username: unishutdown: attempting to shut down

Unicenter TNG 'cal' component...

Jan 5 10:04:00 hserv username: unishutdown: attempting to shut down

Unicenter TNG 'crit' component...

Jan 5 10:04:02 hserv username: unishutdown: attempting to shut down

Unicenter TNG 'opr' component...

Jan 5 10:04:03 hserv vmunix:
-------------------------

As you can see, it stopped at vmunix...


Thanks.

[James Ellis_1]

Dave,

As for sticking the /usr/newconfig/etc/syslog.conf to /etc/syslog.conf...I noticed at another server, these two files were not the same size?

Also, at the problem server, the /usr/newconfig/etc/syslog.conf does not have the last line, /usr/uni/opr/config/server/pipe/oprpipe001 like the corrupt file does.

It appears that the /usr/newconfig/etc/syslog.conf file is from when the system reinitializes, and the last line was added by the unicenter admin?

Thanks.

[Dave Hutton]

It does look like you have some customizations. The one I was pointing to would be like you suggested. As a new install.

Dave

[James Ellis_1]

I am not able to kill the syslog PID. From ls -al | grep syslog, I get the PID of 2344. I try to kill it by executing this command kill -HUP 2344. This PID still shows up when I do an ls. Why cannot I kill it?

Thanks.

[Bill Hassell · Accepted solution]

syslogd is hung so normal kills aren't being seen. Try a kill -3 which will produce a small core dump. The restart syslogd manually. The /usr/newconfig directory contains all the original files before any modifications. The *.info line simply says: take all messages with importance level 'info' and higher, and write them to the long-path/file_name. If the filename refers to a pipe, then only the process that reads from the pipe know what becomes of the data.

[James Ellis_1]

Hi Bill,

Thanks for the help. I tried what you suggest, kill -3 PID, and it is still hung up. I know its hung but forgot how to kill a process short of rebooting the server.

I'd hate to reboot the server as I would have to kick everyone off.

Any other ideas to get around the hung up process state?

Thanks.

[Todd McDaniel_1]

James as a last resort kill -9 is your only option... although I would also try -15 and -18 first...

Then just kill it wiht -9 and restart this way...

/usr/sbin/syslogd -D

[James Ellis_1]

the kill -15 PID did the trick. Thanks for your help, now I got syslog activity!