[Discuss] How does dpkg...

[Patrick]

On Tue, 18 Feb 2014 09:05:02 -0800 (PST)
Alan W. Irwin irwin-at-beluga.phys.uvic.ca |Nixnik-sneaking|
wrote:

> On 2014-02-15 16:11-0800 Patrick wrote:
> 
> > ...Get an exclusive lock on /var/lib/dpkg/lock ?
> >
> > That backup script will wait, if it sees any package management
> > type stuff going on, instead of trying to back-up the system
> > *while* the system is being modified.  You can see how doing
> > otherwise could get ugly, yes?
> >
> > I'd like the script to also get an exclusive lock on the file
> > when its turn comes around, in a way that dpkg will recognize
> > [flock didn't work], then release said lock when finished.
> 
> Hi Patrick:
> 
> It sounds like you want to be able to mix simultaneous automatic
> system updates and backups. If/when you figure out the locking
> mechanism using Brendan's strace suggestion, you might be able to
> implement that possibility, but I have a more fundamental question
> which is why do such complete automation at all?

Oh, I'm not trying to automate software updates, just want the
backup script [which is automated] to wait if a package manager
happens to be active at the time.  That could happen for all
kinds of reasons; maybe I am updating something, installing /
removing something else, or maybe I'm just window-shopping in
Synaptic.

It already checks for that;

while [ "$(fuser /var/lib/dpkg/lock 2> /dev/null)" != "" ]
do
	sleep $(($RANDOM % 22))
	#  Don't try to back things up while packages are being
	#  installed / removed / updated / etc.  Doing so could
	#  result in a broken backup [and a broken system, if
	#  you try to restore from said backup later...].
done

As an added precaution, it seemed like a good idea to *disable*
all package management, at least temporarily, while making a
backup.  But the only way to do it [that I've figured out so far]
has the potential to cause more problems than it solves.

Eh, maybe sitting and waiting is enough.  I can always look at
conky, to see if there's an rsync running in the background.

> 
> I agree that system updating and system backups should be mutually
> exclusive activities, but can't you make sure of that by initiating
> those two activities by hand (or by cron) at completely different
> times rather than attempting to mix them at the same time in a
> completely automated way using a locking mechanism?

I might give it a separate [ana]crontab entry, instead of just
dropping it in /etc/cron.daily/ , mainly because there could be
some waiting involved, and I don't want to hold up other
processes in the meantime.

...Or maybe fork into the background, and wait until `run-parts'
exits.  That would avoid any overlap with software list updates,
logrotate, and other housekeeping jobs.  Would also ensure it
backs-up a freshly tidied system, instead of one that's due for
cleaning.


[...]
> 
> Alan

Patrick.
-- 
Cure the disease and kill the patient.
		-- Francis Bacon