Growing utx.log file

vergilis

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?

jimp

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).

vergilis

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?

jimp

Do you see anything in the main system log about logins/logouts?

vergilis

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 root

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

Let me know what else can be gathered.

Thank you.

charliem

@vergilis:

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

vergilis

Is this how you would recommend to correct gettytab:

/etc/rc.conf_mount_rw
cp /etc/gettytab.bak /etc/gettytab
/etc/rc.conf_mount_ro

And, why this would happen across all the systems? Or, what can be done to mitigate it?

charliem

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?

doktornotor

@charliem:

Is there anything connected to the serial port hardware?

Yeah, sounds like a stuck Enter key is connected there…

vergilis

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.log

Thank you everyone for your thoughts on this.

ApolloDS

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.

ApolloDS

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.

jimp

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.

ApolloDS

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?

jimp

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.

ApolloDS

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.