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.
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).
- 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.
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
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).
The tricky part is the discrimination of 'good' and 'bad' errors.
Ciao,
Gian Piero.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
