Solved Repeated "security prior run still in progress" for weekly security run in root mail

[Nyantastic]

I am receiving repeatedly the above mail message for several weeks from the "weekly security run". Searching for the above phrase does not bring up many results, and I am concerned that the run would still be in progress after several weeks. The controlling script for this seems to be

/etc/periodic/weekly/450.status-security

I cannot see exactly what it runs.

I have not changed any configuration files since installing FreeBSD 11.0 and do not have a file /etc/weekly.local.

 

[ShelLuser]

So basically it's Cron which runs Periodic, see /etc/crontab. So first thing I'd do is to check if Periodic might still be running. If that's the case you may want to kill it and optionally enable logging.

Thing is: Periodic basically checks a selection of things to check for your server status. See also /etc/defaults/periodic.conf, search for "security_status".

 

[tingo]

So what else have you changed on your system? For example, have you added one or more extra filesystems? That could impact the run time for some of the security periodic scripts.

 

[Datapanic]

Check in /var/run/ for old, related .lock files. Might try a reboot and/or deleting them.

 

[Kiiski]

To see what is run, please check /etc/periodic/security/ directory.

 

[Nyantastic]

Check in /var/run/ for old, related .lock files. Might try a reboot and/or deleting them.

There is a file rpcbind.lock in /var/run:

$ ls -l /var/run/rpcbind.lock 
-r--r--r--  1 root  wheel  0 Jun  7 02:17 /var/run/rpcbind.lock

I have not tried a reboot but will consider that next.

 

[Nyantastic]

I rebooted the system immediately after sending the above message, but the "security prior run still in progress" continued.

From root@orange Sat Jul  1 05:30:01 2017
Date: Sat, 1 Jul 2017 05:30:00 +0900 (JST)
From: Charlie Root <root@orange>
To: root@orange
Subject: orange monthly security run output

orange security prior run still in progress

and

From root@orange Sat Jul  1 07:53:05 2017
Date: Sat, 1 Jul 2017 07:53:04 +0900 (JST)
From: Charlie Root <root@orange>
To: root@orange
Subject: orange weekly security run output

orange security prior run still in progress

Is it possible that the daily security run is still in progress each time, and this is causing the delay?

The file system contains a terabyte or more of small files, and the daily security run seems to be running a "find" command which searches through all the files on the system.

 

[Nyantastic]

This problem had been continuing since I wrote the above.

The cron job seemed to be hanging at the stage

Rebuilding locate database:

I edited /etc/locate.rc to remove two directories containing a large number of files.

# paths unwanted in output
#PRUNEPATHS="/tmp /usr/tmp /var/tmp /var/db/portsnap /var/db/freebsd-update"
# 2021-04-09 11:17:07
# Added /hanzi /kanji
PRUNEPATHS="/tmp /usr/tmp /var/tmp /var/db/portsnap /var/db/freebsd-update /hanzi /kanji"

Then I ran

periodic weekly

again and it completed fairly rapidly.

Hopefully this solves the problem.

 

[Deleted member 30996]

This problem had been continuing since I wrote the above
The cron job seemed to be hanging at the stage

Your first post was Jun 19, 2017. Cron has been running on the same job since then?

Hopefully this solves the problem.

Me, too. But what caused it? That is is the question. Let's see...

I get a "daily security run output", "daily run output" and "weekly run output" that all arrive in a timely manner.
The only change I ever make to the Cron default settings, after installing security/rkhunter, is create /etc/periodic.conf with these flags:

daily_rkhunter_update_enable="YES"
daily_rkhunter_update_flags="--update --nocolors"
daily_rkhunter_check_enable="YES"
daily_rkhunter_check_flags="--checkall --nocolors --skip-keypress"

I would venture to guess the answer is hidden somewhere in my last sentence.

I dare do so because since posting my Tutorial on Jul 19, 2017, one month after your OP, my observation has been a lot of the problems people new to FreeBSD have are a result of doing the same thing contained in that last sentence I'm addressing in such a circumlocutionary manner so as not to repeat myself again in hopes you can figure it out if I daredevil dance around the subject til it rains and not rely on dialog dowsing skills alone.

 

[Nyantastic]

Your first post was Jun 19, 2017. Cron has been running on the same job since then?

No, it starts a new job every week but sometimes the previous job is still running (a week later). I had not solved the problem since I wrote the above.

Me, too. But what caused it? That is is the question. Let's see...

As far as I can tell, the file system seems to have too many files for locate.updatedb to cope with. Once I stopped it searching those directories the weekly update job finished in about ten minutes.

I get a "daily security run output", "daily run output" and "weekly run output" that all arrive in a timely manner.
The only change I ever make to the Cron default settings, after installing security/rkhunter, is create /etc/periodic.conf with these flags:

daily_rkhunter_update_enable="YES"
daily_rkhunter_update_flags="--update --nocolors"
daily_rkhunter_check_enable="YES"
daily_rkhunter_check_flags="--checkall --nocolors --skip-keypress"

I would venture to guess the answer is hidden somewhere in my last sentence.

I dare do so because since posting my Tutorial on Jul 19, 2017, one month after your OP, my observation has been a lot of the problems people new to FreeBSD have are a result of doing the same thing contained in that last sentence I'm addressing in such a circumlocutionary manner so as not to repeat myself again in hopes you can figure it out if I daredevil dance around the subject til it rains and not rely on dialog dowsing skills alone.

I haven't looked at your tutorial, I'm sure it is great, but this computer is basically idle most of the time, so I doubt there is some kind of hidden process running looking for cryptocurrencies or whatever it is.

 

[Deleted member 30996]

I wasn't referring to anything stated in the Tutorial or hidden processes running.
I was trying to pin down why it's happening on your box and everything runs like clockwork, as it should around 3am local time, on 8 at last count laptops using the Desktop Oriented OS Of Champions FreeBSD 12.2-RELEASE, with 5 running now.

I edited /etc/locate.rc to remove two directories containing a large number of files.

# paths unwanted in output
#PRUNEPATHS="/tmp /usr/tmp /var/tmp /var/db/portsnap /var/db/freebsd-update"
# 2021-04-09 11:17:07
# Added /hanzi /kanji
PRUNEPATHS="/tmp /usr/tmp /var/tmp /var/db/portsnap /var/db/freebsd-update /hanzi /kanji"

Remove how many Directories?

I'm not up to par but I count 7 Directories in that last line:

PRUNEPATHS="/tmp /usr/tmp /var/tmp /var/db/portsnap /var/db/freebsd-update /hanzi /kanji"

/tmp
/usr/tmp
/var/tmp
/var/db/portsnap
/var/db/freebsd-update
/hanzi
/kanji

Therein lies the crux of my circumlocution.

A lot of the problems people new to FreeBSD have is caused by tweaking this and editing that, not to mention deleting those Directories when one of us can't count correctly by looking at syntax. It may well be me but I don't believe so on this one. Not today.

My /var/db/freebsd-update directory is 187.6MB in size with 384 files and 3 sub-folders. I don't have a folder for Kanji characters and hanzi sounds more like the Japanese film Hanzo the Razor, which I have seen.

FreeeBSD just works for me like nobody else I suppose. I don't do a lot of the editing longtime usr do and learned by finding what needed fixed before I did any editing and then the minimum required.

They just run like atomic clocks with no tinkering by Nuclear Physicists passing near and minimal tweaking under the fingertips of a novice mechanical watch repairman like myself.

That so I don't happen to be at Chernobyl when I thought this was Fort Collins Colorado and it reaches critical mass. Or go into meltdown because I thought there was too much water in that reactor cooling pool and drained some out to where it keep good time. Cause I know what makes watches tick and this isn't the first one I've fixed.

 

[Nyantastic]

I wasn't referring to anything stated in the Tutorial or hidden processes running.
I was trying to pin down why it's happening on your box and everything runs like clockwork, as it should around 3am local time, on 8 at last count laptops using the Desktop Oriented OS Of Champions FreeBSD 12.2-RELEASE, with 5 running now.


Remove how many Directories?

I'm not up to par but I count 7 Directories in that last line:

PRUNEPATHS="/tmp /usr/tmp /var/tmp /var/db/portsnap /var/db/freebsd-update /hanzi /kanji"

/tmp
/usr/tmp
/var/tmp
/var/db/portsnap
/var/db/freebsd-update
/hanzi
/kanji

Therein lies the crux of my circumlocution.

Read the comments at the top of /etc/locate.rc.

 

[Deleted member 30996]

Read the comments at the top of /etc/locate.rc.

Well thank you because that's the first time in 16 years I've bothered to look at it.

Everything in mine is commented out as it was at the end of the Base System Build. There have never been changes made to that file by me on any FreeBSD machine I have ever had. Nothing on that file is run on my machines because they are still commented out and I don't run commands needlessly.

As stated before, that's where new a lot of people new to FreeBSD make mistakes they can't recover from themselves, get frustrated needlessly, it's the Fault of FreeBSD somehow, not theirs and back they go to Linux Land. And they will no doubt be hapopier there then they were here running FreeBSD after they have messed things up to the point of perplexity.

Read the comments at the bottom of /etc/locate.rc.:

# filesystems allowed. Beware: a non-listed filesystem will be pruned
# and if the SEARCHPATHS starts in such a filesystem locate will build
# an empty database.

 

[Nyantastic]

Well thank you because that's the first time in 16 years I've bothered to look at it.

But did you actually look at it though? The next sentence in your post is this:

Everything in mine is commented out as it was at the end of the Base System Build.

Which would mean that it was running using the defaults. You replied to me that I'd added seven directories, but I'd only added two, since the commented-out ones were the defaults.

That's what's described in the comments at the top of /etc/locate.rc. locate.updatedb runs by default as part of the weekly cron job.

There have never been changes made to that file by me on any FreeBSD machine I have ever had. Nothing on that file is run on my machines because they are still commented out and I don't run commands needlessly.

Everything commented in that file is the default, so having it all commented doesn't mean the command doesn't run, it just means it runs the defaults, which the comments describe. That is what it says at the top of /etc/locate.rc, which is why I asked you to read it. The list which I uncommented was the list of things to skip, not the list of things to search, so if you didn't include those directories you'd be running commands needlessly.

As stated before, that's where new a lot of people new to FreeBSD make mistakes they can't recover from themselves, get frustrated needlessly, it's the Fault of FreeBSD somehow, not theirs and back they go to Linux Land. And they will no doubt be hapopier there then they were here running FreeBSD after they have messed things up to the point of perplexity.

Did you combine Linux and BSD, and was the result LSD? Just asking.

Read the comments at the bottom of /etc/locate.rc.:

# filesystems allowed. Beware: a non-listed filesystem will be pruned
# and if the SEARCHPATHS starts in such a filesystem locate will build
# an empty database.

Yes, I read that, I understand what it says, it has nothing to do with my situation.

 

[Deleted member 30996]

Consider yourself ignored.