On 09/01/2014 09:42 PM, Gian Piero Carrubba wrote:
Hi Lorenzo,
sorry I haven't still read the whole thread and all the related bug
reports, so I'm not giving an informed advice. Anyway, given I'm the one
to blame for the '--cron' option, I would like to explain the reasons
for some of the choices.
* [Mon, Sep 01, 2014 at 04:55:09PM +0200] Lorenzo:
Btw, I was thinking that there's another possible solution to this
bug: since /etc/cron.d/apticron runs every hour at some "urandom"
minute, and checks a timestamp file to make sure it's not running more
than once per day, couldn't it just run from /etc/cron.hourly?
Well, it could. I opted differently in order, on one side, to distribute
the burden on the Debian mirrors and, on the other hand, allow a
"not-blocking" execution of apticron on hosts running it (as cron.hourly
serializes the scripts). My opinion is that a "randomized" would be
preferable, but, if that is not possible, this is an option.
You're right, I didn't notice that it would block all other jobs.
That should work even under systemd-cron, and it could __possibly__ be
combined with a couple of additions to the --cron option:
- sleep a random amount of time, up to an hour (since cron.hourly runs
at a fixed minute every hor)
I would suggest not to re-implement this, as this was the old behaviour
and led to the filing of bug #440626 (the fix for which was the
introduction of the '--cron' option).
Funny bug ^^
- flock(1) a file in /var/lock, to make sure there can never be two
instances running (I don't remember when debian switched to /run/lock,
so/var/lock should be safer)
As said, I did not read the whole thread so I'm not sure about the case
you're referring to. As a general note, I think this is not strictly
needed as apticron is meant to be run by cron and if a user run it
manually it's probably just for testing and can cope with an unfortunate
timing.
Np, we all have real lives...
TLDR:
- a cron implementation (bcron-run) used to provide package cron, now
provides the virtualpackage cron-daemon (bug 752506)
- apticron depends on cron, not just any cron-daemon
- apticron cannot just change its dependency because one of the
cron-daemon implementations (systemd-cron) is currently broken and
ignores /etc/cron.d, but it groks cron.{houly,daily,weekly,monthly};
everything else is an attempt to get apticron working even with that
broken package until it is fixed.
Anyway, this is probably part of a long-planned patch that I've never
had the time/wish to implement (or I've simply forgotten about when I
had the time). My intention is to work on it in the next month or two in
order to let it enter at least Jessie (having missed Wheezy), but I
cannot guarantee it. So it would be great if you could consider it while
working on this issue.
Long story short: if apticron run while dpkg/aptitude/apt-get is
running, it will
- update the timestamp (so it will not run in the next 24h)
- fail
- let the user receive a "garbage" mail
In order to avoid these undesired effects, my opinion is that apticron
should
- at the beginning
- take the lock
- if '--cron'
- check the timestamp
- during the execution
- collect STDOUT and STDERR (only if '--cron' ?)
- at the end
- if '--cron'
- if execution was successful
- produce an output
- update the timestamp
- else
- produce an output for some errors but be silent for others
- else
- produce an output (?)
- release the lock
At first sight it makes sense,but I'll need to get acquainted with how
apticron works to say something meaningful about this.
One critical part is the adding of a block that would _always_ run for
removing the locks (so we need to trap all the relevant signals, not
forgetting SIGERR for some shells).
Removal? I didn't mean to use the *existence* of a file as a lock, I
meant to use posix advisory locks, which are unlocked automagically as
soon as your program exits (I suggested flock(1) because it's part of
util-linux and so it should be installed on any debian system).
The only disadvantage is that flock doesn't work on NFS, which could be
a problem for /var/lock/ (not symlinked) but not for /run/lock/
The tricky part is the discrimination of 'good' and 'bad' errors.
Ciao,
Gian Piero.
Ciao,
Lorenzo.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
