[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#459344: /etc/cron.daily/apt exits with return code 1, despite being configured to do nothing


I'm sorry, but I believe you don't fully appreciate what the issue actually 
is. That is the only explanation I've come up with that might account for the 
amount of irrelevant verbiage in your last email (assuming you're not a 
troll - big assumption, considering the rather grand claims you make). Let's 
establish some facts:

apt provides this file: /etc/cron.daily/apt (This is the file I was referring 
to in my email when I said "cron script". Sorry if that confused you.) This 
file is then run daily by cron (or through anacron, when it gets a chance) as 
root. So permissions is not an issue.

Starting at line 176 of that script we have the following code:
# check if we can lock the cache and if the cache is clean
if ! apt-get check -q -q 2>/dev/null; then
    echo "$0: could not lock the APT cache"
    exit 1

Usually when this script is run, apt-get can get the 
lockfile /var/lib/dpkg/lock, the above code succeeds, the remaining code in 
the script, by default, does nothing significant, and everyone is happy.

However, assume now that the user just happens to be running (as root, or 
under sudo) an aptitude (or even apt-get) process while this cron job 
attempts to run. aptitude locks the apt cache while it is running. The 
apt-get check command will then fail as the cache is already locked. It will 
print out the following string (which promptly gets sent to the great bit 
bucket in the sky):
E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily 
E: Unable to lock the administration directory (/var/lib/dpkg/), is another 
process using it?

It's guess is completely correct, of course. Another process does hold the 
lock. This failure, however, causes the cron.daily/apt script to then exit 
with status 1 (the same behaviour as /bin/false, which is what Francesco was 
talking about), and this in turn causes (ana)cron to send an email 
notification to root (and whichever user that mail forwards to) complaining 
that the script failed (exit 1) and with the message that it "could not lock 
the APT cache".

This is all by default, remember, where no files should be autoupdated anyway. 
All the user has to do is be running a process like apt-get or aptitude that 
locks the cache.

Now the user is being notified about errors occurring in /etc/cron.daily/apt 
when 1. they never did anything out of the ordinary, and 2. that script 
shouldn't be trying to do anything anyway. Why should the user be notified 
about this? I agree with you that this is a nuisance, not mission critical. 
However, this is default behaviour of the apt package, and not "entirely on 
the user end", and so it should be addressed like any other packaged 

I suspect the solution involves checking the output of apt-get check -q -q. 
For example, when there actually *is* a problem with permissions, the 
resulting message is:
E: Could not open lock file /var/lib/dpkg/lock - open (13 Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
It looks like checking that string (or maybe the return value itself?) might 
be a possible solution. But I don't know nearly enough about apt's error 
messages to confidently make that call. I'll leave that up to the developers 
to think about.


Lord of, St. Luke Valor wrote (Wed, 16 Jan 2008):
> Francesco,
> I read the original message over again and the obvious diagnosis is that
> somewhere on the host system, permissions are not properly set. Since the
> days of UNIX it has been proper to establish a wheel, which is a group user
> ID that owns processes and daemons, and that also has a very low ID with an
> invisible password. I cannot see whether you have established a password
> shadow file. I do not know whether your system is on a local area network.
> Are you running CVS? RCS? Subversion? Do you know how to lock and unlock
> files? Do you have root access, or at the least superuser privileges? Is
> sudo available to you? Do you have a sudoers file established? Are you
> familiar with /etc/passwd and /etc/shadow, respectively, as I believe they
> are called? I am not sure what your mean with references to /bin/true and
> /bin/false. Are you referring to files on your filesystem? I am at a
> terminal in a public library and can only go by memory. I do not know what
> system administrative techniques are available to you. The problem is not
> mission critical, it is a simple nuisance. It is contained entirely on the
> user end. It is not the Debian project's responsibility. I offered a
> suggestion on the spur of the moment without a Linux system available to
> me. I am a volunteer. I am encouraging you to find ways to contribute to
> the group project with solutions to your own problems. That is how all
> engineering projects are completed. How do I know? I am the original
> implementor of C++. I wrote *The C++ Programming Language* and *Accelerated
> C++*. I learned right alongside Bjarne Stroupstrop and published the first
> text under his name. I have a great deal of experience with solving
> computer-related problems without money or time. Design your own answers to
> problem as standard solutions or they will not be useful for anyone else.
> Start small, contribute often, and you will give a great deal. If you ask
> other people to solve all your problems, no one will.
> Brendon,
> I am not just an elitist medical doctor, I am also an elitist medical
> director. If you "think a bug boils down" to something, you have not
> completed a diagnosis. As the original implementor of C++, I can tell you
> that the most important difference between C and C++ is that C++ always
> returns a value, most often 0, and that is why it is always faster. If a 
> program returns 1 on exit, there has been an error in execution. This has
> been standard for almost 20 years. A cron script runs periodically. It is
> known as a periodic process. The classical UNIX System Adminstration text
> has been revised to cover Linux as well, and is endorsed by Linus Torvalds.
> Every edition of USAH/LSAH has a chapter on periodic processes, and cron is
> the workhorse. Anacron is a derivative. And you, amigo mio, have no idea
> what you are talking about.

Reply to: