Package: fcheck
Version: 2.7.59-19
Severity: normal
Tags: d-i newcomer
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
A: Just leaving the system up & running, generally on my system it
starts to impact the wholesystem performance within 24 hours, because the
fcheck script is launched every 2 hours from cron. As 'fcheck' does consume
quite someresources, every additional instance makes the performanc worse (and
makes it less likely for any of the scheduled processes to ever finish, so the
problem amplifies itself. The effects become severely noticable on the
graphical desktop as well, moving the mouse pointer shows sluggish behaviour,
to the point that it appears that the system has frozen (where in fact is has
not, it's just unimaginably slow). Additional cronjobs from other packages then
also make things worse. I was able to regain control and restore performance
only by ssh'ing into the system and kill all CPU-hogs and duplicate processes
(the duplicate fcheck jobs also caused a few other duplicate cronjobs; those
could also benefit from a check if they aren't already running, but 'fcheck'
was really the root cause).
(NOTE: as described above, fcheck is not the only command or program that is
scheduled to run over-frequently from CRON, I also caught a few others with
similiar behaviour (i.e. that they do not check if their previous instance has
fnished running; ubnfortunately I can't remember which jobs those where.)
* What exactly did you do (or not do) that was effective (or
ineffective)?
A: For the moment, I have changed the command to run from once every 2
hours, to once a day for now.
Since it's written in Perl, I intend to change the script and built in a simple
check using pid- of lock-files under /var/run, with a paranoia check that these
aren't stale, as well as a check of the proces-list in the event that the
proces is running, but has not written a lock-file or pid-file. I am not sure
if I should take into account that concurrent fcheck-process may or should be
possible, when each is checking a different set of directory trees, but at
first sight I can only find a single global configuration, so if concurrent
sessions on different trees may occur, then it probably pertains to a user-
customized instance.
* What was the outcome of this action?
A: For the moment, after killing off the mulitple instances of
'fcheck', it's no longer hogging the CPU's and the sytem is responsive again.
But it hasn't been 24 hours yet, so I can't be sure if the next run will
complete within 24 hours (I know that a single run takes well over 2 hours. I
do not know if this is perhaps the indication of a different problem, and that
the 'fcheck' process really shouldn't take that long.
* What outcome did you expect instead?
A: For now, as only little time has passed, the outcome cannot yet
differ from what I expect. If I find the next 'fcheck' run takes well over 24
hours (or even 12 hours), this would be a serious concern.
GENERAL NOTES & SUGGESTIONS, not pertaining to 'fcheck' allone but the Debian
installation/distribution as a whole:
===================================================================================================================
I am also wondering if the control (checks & balances) on whether the
(previous) jobs have finished), cannot be built into cron - the scheduler that
launches the jobs. Perhaps rather than launching or forking off the job in the
backgroup and never look back at its children, cron could be changed to only
launch a new scheduled process if its certain that the previous one has
terminated?
On a general note to the maintainers that consolidate all packages to 'a full
distribution', I believe that some thought should be given to packages that
require/install cron-entries, and should question if the commandsor jobs should
really run as often as the package maintainers suggest (or populate the at- and
cron tables) and that the package maintainers should justify with valid
arguments how often they find that their (package) jobs should be scheduled,
taking into account how long they may run on less powerfull systems, and also
that for a standard installation, I find there are really *a lot* of cron
entries (compared to some years ago). Are they really all necessary (and do
they need to run so frequently?). Especially for less knowledgable users, this
is a mysterious portion of the system configuration where it's hard to
ascertain from the crontable itself/allone what the impact is of disabling or
decreasing the frequency of jobs. Kindly take this into consideration.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages fcheck depends on:
ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4
ii file 1:5.32-1
ii mailutils [mailx] 1:3.2-1
ii nocache 1.0-1
fcheck recommends no packages.
fcheck suggests no packages.
-- Configuration Files:
/etc/cron.d/fcheck changed [not included]
/etc/logcheck/ignore.d.server/fcheck [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.server/fcheck'
-- no debconf information
