Bug#459344: /etc/cron.daily/apt exits with return code 1, despite being configured to do nothing
Luke,
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
fi
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
unavailable)
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
nuisance.
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.
Peace,
Brendon
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: