Solaris 10 massive SMF log file

I found that there was a SMF log file: /var/svc/log/milestone-multi-user-server:default.log.0 which occupied around 19G bytes.
Please help me how to purge this massive file.
Can I just use cat /dev/null > /var/svc/log/milesto..... to this file without any interruption to a non-stop system?
Please Help.

I would keep the very end of the log and delete the rest:

 
tail -n-1000 /var/svc/log/milestone-multi-user-server:default.log.0 > /var/svc/log/milestone-multi-user-server:default.log.0
 

That would truncate the logfile to length zero, because the redirection is handled by the shell before the tail command can do it's work.

As for the original question. You can truncate the logfile, as long it is not open. You can check with

# /usr/sbin/fuser /var/svc/log/milestone-multi-user-server:default.log
/var/svc/log/milestone-multi-user-server:default.log:

If there is a process number after the colon, the file is open, like here:

/var/svc/log/system-filesystem-autofs:default.log:      965o     964o

Thanks all.
In this case , how can I truncate the log file if it is open?

You already know how:

cat /dev/null > /path/to/logfile

This will zero the file without interrupting any processes that had it open.

That's not guaranteed to work.

Depending on how the file was opened, how it's written to, and the specifics of how the underlying file system handles attempts to write past the end of a file, you could wind up doing nothing more than creating a file every bit as large as it was, only whatever data that was in the file is lost.

Here's what happens:

1. A process has an open file descriptor on a file, and the file was not opened in "append" mode.
2. File is truncated to zero bytes by an outside process.
   Note that file descriptors have a "current" offset associated with them, and operations outside the process do not effect that position.
3. The process writes to the file, and the bytes go to the original pre-truncation "current" offset in the file.
4. If the underlying file system does not support sparse files, it's back to being 19GB. If the file system does support sparse files, an "ls -l" will still show the file as being 19 GB, but a "du" will show that the file actually uses much less space.

And all bets are off if a process has a file memory-mapped and the file is truncated out from under the mapping. Just try truncating a binary executable when a copy of that binary is running....

For this issue, can logadm command to saftey truncate "milestone-multi-user-server:default.log.0" or setup a command line inside logadm.conf and let O/S to automatic truncate, keep rotate the file in 3 and limit the file size to 10M.
Thanks!

There is already (stock out Solaris 11) entry in /etc/logadm.conf
smf_logs /var/svc/log/*.log -C 8 -s 1m -c

On solaris 10 (i only have x86, above is new sparc), default smf_logs does not seem to have -c option by default (so it is copying the file without truncating).

Regards
Peasant.

A couple of comments:

• The chances the OP file system used to store the log file doesn't support sparse file is zero, it is very likely ZFS or UFS.
  
  
• cat /dev/null is pointless, it does nothing useful despite popular belief so can be replaced by the no-op shell command : for the same effect:
  text : > /path/to/logfile
  or even by nothing with most shells:
  text > /path/to/logfile

Try running "cat" or "grep" on a 300 GB or larger sparse file.

And imagine what kinds of fun will happen after that sparse file grows to a few terabytes in size and an admin who doesn't understand sparse files sees that it's "bigger than the entire file system".

People aren't going to be cat-ing a 19-gigabyte sparse log file that, yesterday, they didn't even knew existed.

It's not ideal for all circumstances, no, but it ought to work here.

That should be faster than with a same size non sparse file. Anyway, I assumed the primary goal of the OP was to save disk space which the redirection does. My other point was about the cat /dev/null urban legend.

The sooner (s)he learns the better !