Growing utx.log file
-
On all of my amd64 nanobsd v2.2 pfsense systems, the /var/log/utx.log file seems to grow indefinitely, until /var runs out of disk space. Does anyone have recommendations on how to correct this?
-
That shouldn't be a large log file, unless something is continuously logging in and out repeatedly.
I'm not even sure we have any of the utilities included to read that log (such as /usr/bin/last).
-
Like I mentioned, this problem only exhibits itself on amd64 2.2 nanobsd. All of the i386 nanobsd 2.2 are fine. What additional information do you need to troubleshoot this?
-
Do you see anything in the main system log about logins/logouts?
-
Several different amd64 bit systems have the following message in the logs every 30 seconds:
init: getty repeating too quickly on port /dev/ttyv0, sleeping 30 secs
init: getty repeating too quickly on port /dev/ttyv0, sleeping 30 secs
login: login on ttyv0 as root
login: login on ttyv0 as root
login: login on ttyv0 as root
login: login on ttyv0 as root
login: login on ttyv0 as rootAll of the systems have this implemented: https://doc.pfsense.org/index.php/Why_do_I_get_%22login_on_console_as_root%22_messages_in_the_logs
Let me know what else can be gathered.
Thank you.
-
init: getty repeating too quickly on port /dev/ttyv0, sleeping 30 secs
All of the systems have this implemented: https://doc.pfsense.org/index.php/Why_do_I_get_%22login_on_console_as_root%22_messages_in_the_logs
That will suppress the messages for successful logins, but won't suppress the getty respawning messages.
Check for a corrupted file /etc/gettytab
-
Is this how you would recommend to correct gettytab:
/etc/rc.conf_mount_rw
cp /etc/gettytab.bak /etc/gettytab
/etc/rc.conf_mount_roAnd, why this would happen across all the systems? Or, what can be done to mitigate it?
-
Sorry, I don't run any nano pfSense installs. It happens on all your systems, so it would seem to be a systemic issue rather than random.
On my (non-nano) installs, the files gettytab and gettytab.bak are identical. Check to see if yours are different (diff -ub gettytab gettytab.bak); if so, yes, try to use the bak file like you wrote. If they are the same, check the contents, as the bak file may have been created with the same errors as the original.
Is there anything connected to the serial port hardware?
-
Is there anything connected to the serial port hardware?
Yeah, sounds like a stuck Enter key is connected there…
-
All of the nanobsd firewalls did not have any corrupted /etc/gettytab
Reloading init and removing the log file seems to have addressed the issue everywhere:
kill -1 1
rm /var/log/utx.logThank you everyone for your thoughts on this.
-
Hello
We have the same problem and I know why.
We use the check_mk package which is used to monitor the pfSense firewall. For this to work we do the monitoring over an ssh login.
So every 5 mins the monitoring is login to get the check_mk informations and logout again, this fills up the /var/log/utx.log.Since we don't have any tools to use the utx.log file is there any possibility to remove the creation of the /var/log/utx.log and /var/log/utx.lastlogin? I think they're not needed in pfSense.
And on Nanobsd installs this is really fast happening, filling up /var partition. -
Answering my own question, found the following workaround:
Just do a soft-link to /dev/null:
ln -sf /dev/null /var/log/utx.log
Since there is no 'last' command installed I think you cannot use /var/log/utx.log.
-
last and lastlogin are there on 2.3. You might be OK to /dev/null that but there are some things out there that require utx so don't be shocked if you have a problem over time.
-
Hi jimp,
This installation is still 2.2.4 and there it was not included. In 2.3.x it is.
So what about some retention for utx.log? -
Whether or not the utilities to read utx.log are present, the file may still have use by other parts of the OS.
It may work fine just be aware of the potential that it might cause an issue. If it's really growing that fast you need to find out why and fix the real problem. If it's growing due to a legitimate use, then perhaps a periodic truncation of the file would be more appropriate in your case.
-
Hi jimp,
Thanks for the ultrafast reply :-)
Yes indeed, it's the check_mk package. We're monitoring with it the firewalls and then we have all 5 minutes a login to the firewall via ssh from the monitoring host.
I know check_mk can be used over a tcp-port but our development here decided to use it strictly over ssh, even when problems like this arise. (Which I don't understand why over ssh).On my private installation I'm using Zabbix as the monitoring, much more advanced, also encrypted direct agent/proxy communication and also great it is supported as a package by pfSense ;-)
No problems with the Zabbix Agent there.