pkg starves other processes

This A.M. I discovered that our imap service was experiencing some sort of performance issue. When I looked into this I discovered this situation at about 08:31:
Code:
# ps -auwx | grep pkg
root    56759  0.0  0.0  11804  2856  -  IJ   07:01   0:00.00 /bin/sh - /usr/local/etc/periodic/security/460.pkg-checksum
root    57841  0.0  0.0  11804  2840  -  IJ   07:01   0:00.00 /bin/sh - /usr/local/etc/periodic/security/460.pkg-checksum
root    58086  0.0  0.0  20240  9512  -  IJ   07:01   0:00.00 /usr/local/sbin/pkg check -qsa
root    58843  0.0  0.2 122512 73552  -  DJ   07:01   0:29.21 /usr/local/sbin/pkg check -qsa

It appears that periodic started two identical pkg processes at the same time. It also appears that these interfered with each other in some manner so as to prevent completion of either and to consume an excessive amount of system resources. I killed all of them and then the mail delivery service returned to normal.

A few questions arise:

1. How is it that two identical processes were spawned by periodic at the same time? How can this be prevented?

2. Should pkg be implemented either as a singleton or incorporate a semaphore to prevent this interference?
 
1) Do you have one or more jails running on that host? Looking at the "J" in the process-list, I'm going to say, yes? Remember, each jail has a cron running, thus also a periodic(8). They're going to run all at the same time. Modify /etc/crontab on each jail, to spread the timing so they're not all starting at exactly the same time.
2) They're running in different jails. They're technically not running concurrently.
 
1) Do you have one or more jails running on that host? Looking at the "J" in the process-list, I'm going to say, yes? Remember, each jail has a cron running, thus also a periodic(8). They're going to run all at the same time. Modify /etc/crontab on each jail, to spread the timing so they're not all starting at exactly the same time.
2) They're running in different jails. They're technically not running concurrently.
That must be it. Thanks. I seem to recall running into this before.
 
I know that I did this before but I could not find it using search.
Code:
###  /etc/rc.conf
# Jitter root cron jobs between 0 and 60 seconds after scheduled time
cron_flags="$cron_flags -J 35"

Updated - maximum permitted jitter value is 60.
Code:
# service cron start
Starting cron.
cron: bad value for root jitter: 180
/etc/rc.d/cron: WARNING: failed to start cron
So Beware.
 
Last edited:
Back
Top