Showing results for 
Search instead for 
Did you mean: 

Pros and Cons of using over Solaris logadm utility for LMS v3.2


I've been going back and forth with development on a way of best leveraging a log rotation capability in our newly deployed LMS 3.2 rollout on Solaris 10.

My issue:

As of now, we use the services facility built into Solaris to start/stop the syslog service and logrotate (via logadm) our LMS log file (syslog_info) on a weekly basis.  I added an argument in logadm to HUP the syslogd service which I think resets the file pointer and/or forces syslogd service to re-read the syslog.conf file. The problem with this setup is that in order for me to logrotate, I additionally have to stop and start a whole chain of processes so that the LMS application can carry on its duties of collecting and analyzing this data.  So what I would have to do without drilling down a lenghty process dependencies is to stop/restart LMS which I really dislike doing for a small part of the entire application suite.

Cisco TAC recommends that insead of using logadm, that we should use which I have used in the past on a limited basis.  TAC informs me that this will essentially logrotate and stop/start the LMS as well but what I haven't been able to get out of them is how this script deals with the syslog service. I looked over the code but didn't see any reference to the actual syslog service.

In summary, I need to know:

1) why is preferred over logadm.

2) how does handle the syslog service.

Your feedback would be most appreciated...


Joe Clarke
Hall of Fame Cisco Employee

The main advantage of logrot is that it rotates the file in place without modifying the inode number.  It also hass some Daemon Manager knowledge built in.  With syslog_info, logadm is perfectly fine provided you use the "-c" argument to logadm.  This will do an in-place rotation, and no daemons will need to be restarted.

Hi Joe,

thanks for the reply.  I'll have to do some experimentation with this before I proceed but what you said makes sense.

Take care.

Michael Mione