Hello,
I am trying to rotate my logs using logadm, so I did the following
logadm -w /traces/mylogs.out -C 5 -p 1d -o user -g group -m 644 -c -t '/traces/mylogs.out.$n' -z 1
and then tried to test it by logadm -v and it gets stuck at truncation step
# processing logname: /traces/mylogs.out
mkdir -p /traces # verify directory exists
# log rotation via atomic copy and truncation (-c flag):
# copy /traces/mylogs.out to /traces/mylogs.out.0
# truncate /traces/mylogs.out
^C
I actually had to stop its processing because it took longer time and can see it eats my diskspace by creating a file with blank lines
# du -sh mylogs.out*
76M mylogs.out
29G mylogs.out.0
when I checked mylogs.out.0, I found it is just full of blank lines which I don't understand why!
Could you please advise in this?
Thanks.
I believe that I followed the exact instructions there, still not working 
---------- Post updated at 07:43 PM ---------- Previous update was at 04:21 PM ----------
I noticed also something in the logs permission -rw-r-lr--
What does ( l ) in the middle mean here? I am not sure if this is because of my action?
Normally you do not need -o user -g group -m 644 because it picks the attributes from the logfile.
(The same feature was in the Linux logrotate, until they found a security bug in connection with its globbing feature.)
To your problem:
according to man ls the l or L means "mandatory locking" and can indeed cause a problem, e.g. logadm or cp waits until the lock is released.
Can you manually cp the logfile?
Hi,
Thanks for the notes 
Good to know that!
The problem is solved after restarting the process to force recreating the log in a clean manner.
It looks that my intervention to free it by redirecting /dev/null to it, caused this issue I think!
Anyway after removing it and starting the process, I was able to apply logadm on it with no problem using the same command.
Thanks.
Sometimes the better alternative is to not use the -c option,
instead signal the process to close/open its logfile by means of the -a option.