Hi Sergii,
Thanks for reply.
In line with your directions, I did further look at the case...
Master> show configuration system | display set | match traceoptions
set system processes dhcp-service traceoptions file dihescipi_logfile
set system processes dhcp-service traceoptions file size 10m
set system processes dhcp-service traceoptions level all
set system processes dhcp-service traceoptions flag all
set system processes app-engine-virtual-machine-management-service traceoptions level notice
set system processes app-engine-virtual-machine-management-service traceoptions flag all
Master> file list /var/log/*_log* detail
-rw-r----- 1 root wheel 7170715 Mar 15 13:07 /var/log/dihescipi_logfile
-rw-r----- 1 root wheel 796877 Mar 15 13:06 /var/log/dihescipi_logfile.0.gz
-rw-r----- 1 root wheel 787786 Mar 15 13:05 /var/log/dihescipi_logfile.1.gz
I have some qs to you:
Q1) Clearly this traceoption is still enabled. How to make sure this traceoption is not working for any automation purpose before making it deactivated or delete.
Q2) I don't think so this file was created today (Mar 15) as last commited date 5 month ago but not related to this file at that time. So how to find when this traceoption file was created and who? (my applogy this file was not created previously! We don't know when and who created). ">sh sys rollback compara 0 1" with this command, each time needs to performed until commit 49 to see change conf that related to this traceoption file. This way is really spending waste of time. Is there a efficient way or scripting to figure out the case? If so, can you explain pls.
Q3) As this traceoption is still running, why we are not seeing any warning or error that says storage exceeding volume or many creating files ext as we are seeing one of the Juniper strong recommendations is disabling traceoption when it is not using or capturing the packet.
Thx.