UNIX for Dummies Questions & Answers

Hello All,

Server: SUSE Linux Enterprise Server 11.3 (x86_64)

Syslog-ng Version: syslog-ng 2.0.9

We have configured a Cisco router to send it's log messages to this server listed above. This has been working just perfectly
for the last couple months, but we had never setup the log rotation part of it and the log file was getting extremely large.
So I decided to manually move the current log file to a new file and then ran touch on the original log filename to re-create it.

Code:

/var/log# mv remote.syslog.log remote.syslog.log_20140925
/var/log# touch remote.syslog.log
/var/log# chmod 640 remote.syslog.log
/var/log# bzip2 -z remote.syslog.log_20140925

I did this so I could compress the original log file with bzip2 seeing how large it was getting... Now, the log messages
from the router are not being written to the log file anymore. I ran Wireshark and I could see the router sending the messages,
to the server, yet nothing is being written to the log file anymore...

Did I mess this up somehow by moving and re-creating the original log file?

If anyone knows how I can fix this please feel free... But any thoughts or suggestions would be greatly appreciated!

Thanks in Advance,
Matt

You need to tell syslog there's a new log file by hupping (kill -hup PID) it...

Did you HUP the running syslogd process?

I bet if you look under /proc for your syslogd process, you'll find the original log file still open under /proc/PID/fd/

Hey Guys, thanks for the replies!

No I haven't tried that... But I think your right... Check this out:

Code:

nagios:/proc/2975/fd # ll
total 0
lr-x------ 1 root root 64 Sep 25 16:44 0 -> /dev/null
l-wx------ 1 root root 64 Sep 25 16:44 1 -> /dev/null
l-wx------ 1 root root 64 Sep 25 16:44 10 -> /var/log/mail.info
l-wx------ 1 root root 64 Sep 25 16:44 11 -> /var/log/messages
l-wx------ 1 root root 64 Sep 25 16:44 2 -> /dev/null
lrwx------ 1 root root 64 Sep 25 16:44 3 -> socket:[131564428]
lrwx------ 1 root root 64 Sep 25 16:44 4 -> socket:[131564430]
lrwx------ 1 root root 64 Sep 25 16:44 5 -> /dev/xconsole
l-wx------ 1 root root 64 Sep 25 16:44 6 -> /var/log/remote.syslog.log_20140925 (deleted)
l-wx------ 1 root root 64 Sep 25 16:44 7 -> /var/log/mail
lrwx------ 1 root root 64 Sep 25 16:44 8 -> /dev/tty10
l-wx------ 1 root root 64 Sep 25 16:44 9 -> /var/log/warn

So would I run something like:

Code:

# service syslog-ng restart

Also, what does the "-hup" part of the kill command do?

Thanks again for the replies, much appreciated!

Thanks,
Matt

---------- Post updated at 04:51 PM ---------- Previous update was at 04:46 PM ----------

Ok, so I ran the following and now the log file is being written to again.

Code:

# service syslog restart

Thanks for the help guys, much appreciated!

Thanks Again,
Matt

kill (somewhat misleading name!) sends signals to processes; use kill -l to list all of them. Processes react on signals, e.g. by "committting suicide when tapped on their shoulder and asked to do so" by the TERM signal. HUP (hangup) is one of them. syslog uses it to reread its config and if need be start a new logfile. So no restart necessary for a new file...

To expand on what RudiC (correctly) explained:

When a process (your syslog for example) writes to a file it has to open it first. To "open it" means issuing a system call fopen(). The OS gives back a "file handle" by which the process now can access the file (until it closes it, which means issuing another system call).

This file handle now identifies the file not by its name but by a more "personal" identification: the inode number. When you delete the file and create a new one with the same name in its place then exactly this has happened: a new file with the same name is in the place of the old file, but the new file and the old file are still distinct files and they have different inode numbers.

Think of it like this: some "John Smith" lives in an appartment. When he moves out and another guy, incidentally also named "John Smith", moves in, they are still not the same person, yes?

Therefore, until told otherwise, your process still writes into the old file, even if it is no longer visible because you deleted it. It even takes space on your harddisk until your process holds it open. Only when you stop the last process holding it open (more than one process could open a file simultaneously) it will be finally "unlinked" - the space it takes will be relinquished and its data be destroyed.

With sending a signal to the process you tell it to "start over": re-read its configuration files, open the necessary files anew, etc., similar to stopping and restarting it, but without the actual program stop and program start.

I hope this helps.

bakunin

Hey RudiC/bakunin, thanks for the replies!

Ok gotcha, makes sense... Thanks for the detailed explaination, much appreciated!

Yea, I was slightly familiar with signals but just a little... The only other thing I used kill for (*other then killing a process) was to
send the USR1 or SIGUSR1 signal to check the status of dd. But that's good to know. I assume you could use that for most
daemons that are running?

Thanks Again,
Matt