Description of problem: After upgrading anacron to the latest available, a strange message is sent by email by, I guess, anacron itself. Version-Release number of selected component (if applicable): 2.3-38.FC5 How reproducible: Well, always after a daily restart, at least so far I had the opportunity to see. Steps to Reproduce: 1. Not too much, restart the PC after one day and wait the different cron/anacron jobs to be excuted. 2. 3. Actual results: An email arrives with: ... From: root@mypc (Anacron) ... Subject: Anacron job 'cron.daily' /etc/cron.daily/0anacron: anacron: Cannot run - another anacron process is already running.: Resource +deadlock avoided Expected results: I would say this email should not occurr, whatever the reason. Additional info: All the rest seems to work properly, for example logwatch is scheduled and executed normally.
i see this too, this has been discussed in the fedora.users list as well (although no solution so far)
The problem is simply that you already have the anacron service running from /etc/init.d/anacron, so when the cron.daily/0anacron script tries to run anacron, it correctly fails and does not run another anacron instance. anacron now implements a lock file mechanism, to allow the service initscript to behave correctly when changing run levels. It now emits a message when it finds it cannot run due to another anacron process already running, which is then the output of the cron.daily cron job and is mailed to you by crond. There is an easy workaround - either: o Do not run anacron as a service : # chkconfig --level=0123456 anacron off OR o Do not put an anacron run in cron.daily - # mv /etc/cron.daily/0anacron /etc/cron.daily/.disable_0anacron It is rather silly to both run anacron as a service and put an anacron run in cron.daily - particularly as anacron will then always try to run itself. I will look into perhaps removing the emission of the message 'Cannot run - another anacron process is already running' if stdout is not a terminal. This will shortly become academic as anacron is being replaced by a crond that keeps a persistent job database and supports anacrontab syntax and anacron behaviour.
(In reply to comment #2) > It is rather silly to both run anacron as a service and put an anacron run > in cron.daily - particularly as anacron will then always try to run itself. Well, OK, but I did not set the system in this way, I just upgraded. Would have it been better to clean up things, i.e. disabling anacron as service _OR_ as cron.daily job, in the upgrade script? Anyway, maybe it is enough to remove the mailed error. Thanks.
The 0anacron script in cron.daily calls anacron -u, which is supposed to just update the timestamps, not do a full anacron run. That's not "silly", the purpose is to make sure anacron knows when the cron.daily scripts were last run, no matter if they are run by anacron or by regular cron. The suggested "workaround" is completely stupid, as it breaks an essential system service just in order to stop a harmless message from appearing.
I am experiencing this bug also. What is the correct way to deal with this issue? It sounds like the cron.daily run serves a purpose and running anacron as a service is also benificial. Regardless, preventing the message to admin should continue and a correction to make things correct should be dealt with.
Correction for the regardless: The message regarding the error should continue being sent to admin. A correction to the collision because of the lock file should be implemented.
The problem can be fixed by changing the /etc/cron.daily/0anacron script: #!/bin/sh # # anacron's cron script # # This script updates anacron time stamps. It is called through run-parts # either by anacron itself or by cron. # # The script is called "0anacron" to assure that it will be executed # _before_ all other scripts. # Don't run anacron if this script is called by anacron. if [ ! -e /var/run/anacron.pid ] then anacron -u cron.daily fi /etc/cron.weekly/0anacron and /etc/cron.monthly/0anacron scripts need a similar change.
Well, it seems we got a solution (or "the" solution?). As my boss use to say: when will it be available in the updates? Thanks.
*** Bug 194081 has been marked as a duplicate of this bug. ***
Since I switched to FC5 I begun to observe the "strange" e-mail message ... I got rid of it by removing anacron from the service startup list. What I still do not understand is that I have observed an unusual activity of the LED indicating the Hard Disk operation. Once this activity is started it will not cease unless the system is restarted . I am not sure about the correlation between the unusual HD activity and the anacron issue ... I have observed that at least ten times and, when this happens, I ALWAYS get the message. I have moreover observed another unusual behavior : when the system tries to start anacron twice it also tries to kill it twice at system shutdows. The SECOND ATTEMPT OBVIOUSLY RESULTS IN A FAILURE, indicated by a RED CHARACTER MESSAGE in the shutdown output.
*** Bug 202463 has been marked as a duplicate of this bug. ***
Patch to the spec file: Index: anacron.spec =================================================================== RCS file: /cvs/dist/rpms/anacron/FC-5/anacron.spec,v retrieving revision 1.19 diff -r1.19 anacron.spec 69,70c69,72 < anacron -u $i < --- > # Don't run anacron if this script is called by anacron. > if [ ! -e /var/run/anacron.pid ]; then > anacron -u $i > fi
I dissagree with Jason that this is not a bug. I successfully reproduced the bug and have to say, that this is really annoying :) However, I did not see such a behavior described in comment #10. As for the reported bug itself, I just added a test to check whether anacron is running, pretty the same as in comment #12.
I've implemented the fix from comment #7, but now I'm seeing completely empty email messages, though not sure it happens every time yet. It's definitely from cron.daily. Return-Path: <root.nwra.com> Received: from lynx.cora.nwra.com (lynx.cora.nwra.com [192.168.0.56]) by earth.cora.nwra.com (8.13.7/8.13.7) with ESMTP id k7UGufXU011586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <root.nwra.com>; Wed, 30 Aug 2006 10:56:41 -0600 Received: from lynx.cora.nwra.com (localhost [127.0.0.1]) by lynx.cora.nwra.com (8.13.7/8.13.7) with ESMTP id k7UGuf3V008995 for <root.nwra.com>; Wed, 30 Aug 2006 10:56:41 -0600 Received: (from root@localhost) by lynx.cora.nwra.com (8.13.7/8.13.7/Submit) id k7UGuee2008985 for root; Wed, 30 Aug 2006 10:56:40 -0600 Date: Wed, 30 Aug 2006 10:56:40 -0600 From: Anacron <root.nwra.com> Message-Id: <200608301656.k7UGuee2008985.nwra.com> Status: O X-UID: 30331 Content-Length: 0 X-Keywords: From /var/log/cron: Aug 30 10:56:40 lynx anacron[2670]: Job `cron.daily' terminated (mailing output)
Hm... so the problem could not be fixed so easily. The solution could be in changing the way anacron informs the root about errors.
(In reply to comment #14) > I've implemented the fix from comment #7, but now I'm seeing completely empty > email messages, though not sure it happens every time yet. It's definitely from > cron.daily. ... > From /var/log/cron: > > Aug 30 10:56:40 lynx anacron[2670]: Job `cron.daily' terminated (mailing output) > Strange. I tried a different thing. I just commented out the line: anacron -u cron.daily That is (to be clear): #anacron -u cron.daily No empty mail was sent, no mail at all. In theory, the proposed solution should have the same effect and, from anacron documentation, the mail is sent _if_ output is generated. So, I don't know, could it be the proposed solution has anyone some output, maybe just CR? /bin/sh is a link to bash, could this affect the behaviour? I'll try the "if" solution and report the result.
OK, from the test I could perform (on a different PC), no mail message was sent with the solution of comment #7 (empty or full), so I guess something else is wrong with the result of comment #14. I must say that /etc/cron.daily was executed by anacron, from what I could see, and not by crond (the PC was freshly booted). I do not know if this makes a difference in terms of mailing. In case it does, maybe there is an other bug to consider. In my opinion the patch should go mainstream and see how many reports are generated.
The problem with anacron sending empty mails is indeed a different bug. It also occurs when anacron is run directly and not via cron. I have file a new bug report here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205747
Please upgrade on anacron-2.3-40.fc5, and let me know. I haven't these annoying mail since update.
With anacron-2.3-40.fc5, /etc/cron.daily/0anacron is still: # cat /etc/cron.daily/0anacron #!/bin/sh # # anacron's cron script # # This script updates anacron time stamps. It is called through run-parts # either by anacron itself or by cron. # # The script is called "0anacron" to assure that it will be executed # _before_ all other scripts. anacron -u cron.daily and still produces: anacron: Cannot run - another anacron process is already running.: Resource deadlock avoided please apply the patch from comment #12.
To corroborate the report in comment 20, I am using anacron-2.3-40.fc5, and still get the "process is already running" email from anacron.
Patch is applied in anacron-2.3-41.fc5