Delete syslog but size disk can't increase

UNIX Solaris
1

Hi Experts,

I have a problem wih /var. Disk /var is full. After i investigate, i found file /var/log/syslog.0 is growing rapidly. The size is 4.3G. I tried to move syslog.0 to another disk and file was moved successfully.

My question is why size /var can't increase? used space still 100%.

When i check the size of syslog.0 in place that i moved, the size is 4.3G. But free space of /var still 0%

I'm using Solaris 10.

Please share your thought/experience.

Thanks
Edy

2

If that file is still open and used by e.g. syslogd, it cannot be unlinked and still exists on the disk, probably with another name. If existent on your system, try lsof to check open files. Some syslogds react on kill -HUP by closing their files (and doing other things, read man page!) and releasing allocated disk space.

3

Hi Rudic,

Thanks for your valuable suggestions.

I found process syslogd. I must stop the syslogd process before delete file or what?

if i delete this file, there is no impact to the system?

it's save if i used command > /var/log/syslog.0 ?

Sorry for my basic question, because i'm newbie in solaris.

Thanks
Edy

4

Are you able to identify the files opened by process syslogd (e.g. lsof -c syslogd )? Check the man page for ways to talk to syslogd, e.g. kill -HUP , so you can tell it to close its files without stopping the process.

5

If you've deleted the file, then you have to kill whatever process has it open to close and remove it from disk.

If you hadn't deleted the file, you could've simply truncated it -- overwritten it with an empty file -- to reduce its size to zero.

6

Not necessarily.

It would depend on how the file is being written to by the process(es) that are writing to the file, and the file system in use.

If the file is being written to in append mode, truncating the file out from under the process(es) will probably work to reduce its size permanently.

If it's not being written to in append mode, after you truncate it down from, say, 10 GB to zero, the next time the process(es) write to the file, they'll still do so at the old 10 GB file offset. What happens then depends on whether or not the underlying file system supports sparse files.

And that's just if you're doing it all on a single machine. If it's a shared file (NFS, some other shared file system), things can get really fun.

7

Try this first:
syslogd responds to the SIGHUP signal.
So, edit the entries in the /etc/syslog.conf to direct to another file eg /someplace/log/syslog instead of the current setting. After that,

kill -HUP <pid of syslog daemon>

to "reinitialize" the config

If that does not meet your needs then:
This stops the sylogd process, which is not a good idea longterm

svcadm disable svc:/system/system-log:default

Delete files, edit the syslog.conf file to suit your needs. Since the log is filling up fast you might want to turn of some of the less useful messaging.
Turn syslog back on

svcadm enable svc:/system/system-log:default
1 Like
8

Thank you all for your valuable response.