three snapshots created

[Nafallo Bjälevik]

 Hi,

It seems we get three snapshots created when ran from update-manager, but only one when used with apt-get manually from the terminal. Not sure how to help debug it, but let me know how and I'll try my best to make the effort.

nafallo@parakeet:~$ sudo apt-btrfs-snapshot list | tail -n5
@apt-snapshot-old-root-2011-09-17_09:40:37
@apt-snapshot-2011-09-17_09:53:36
@apt-snapshot-2011-09-17_09:53:46
@apt-snapshot-2011-09-17_09:53:56
@apt-snapshot-2011-09-17_10:19:14

Cheers, /N

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: apt-btrfs-snapshot 0.2
ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
Uname: Linux 3.0.0-11-generic i686
NonfreeKernelModules: wl
ApportVersion: 1.23-0ubuntu1
Architecture: i386
Date: Sat Sep 17 10:27:01 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release i386 (20110427.1)
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: apt-btrfs-snapshot
UpgradeStatus: Upgraded to oneiric on 2011-08-23 (24 days ago)

[Nafallo Bjälevik (nafallo)]

Oh, should probably mention this isn't a regression. I've always seen the issue since I installed the package. Just neglected to actually report the bug until now.

[MatthewHawn (steamraven)]

I have witnessed this too. This actually becomes a problem if it is called more than once in the same second: apt-btrfs-snapshot discards the microsecond when creating the snapshot name. Since the subvolume (snapshot) already exists on the second call, btrfs dumps the second snapshot WITHIN the first.

This creates something like:

sudo btrfs subvolume list -p .

ID 256 parent 5 top level 5 path @
ID 305 parent 5 top level 5 path @apt-snapshot-2012-06-20_09:33:18
ID 306 parent 305 top level 5 path @apt-snapshot-2012-06-20_09:33:18/@

This will prevent @apt-snapshot-2012-06-20_09:33:18 from being deleted because it has a child subvolume. This might cause: Bug # #997909.

I am not sure what happens if more than two snapshots happen in the same second. I would assume the third would fail looking like: #853849

Simple solutions: keep the microseconds or add a random (or incrementing ) postfix

[Sanjeev Gupta (ghane)]

I can confirm this:

root@precise-X201:~# btrfs subvolume list -p /
ID 256 parent 5 top level 5 path @
ID 269 parent 5 top level 5 path @apt-snapshot-2012-02-06_10:57:25
ID 270 parent 269 top level 5 path @apt-snapshot-2012-02-06_10:57:25/@
ID 271 parent 5 top level 5 path @apt-snapshot-2012-02-06_10:57:26
ID 272 parent 271 top level 5 path @apt-snapshot-2012-02-06_10:57:26/@
ID 282 parent 5 top level 5 path @apt-snapshot-2012-02-07_10:39:29
ID 283 parent 282 top level 5 path @apt-snapshot-2012-02-07_10:39:29/@
ID 302 parent 5 top level 5 path @apt-snapshot-2012-02-21_11:31:14
ID 303 parent 302 top level 5 path @apt-snapshot-2012-02-21_11:31:14/@
ID 440 parent 5 top level 5 path @apt-snapshot-2012-04-23_14:12:51
ID 441 parent 440 top level 5 path @apt-snapshot-2012-04-23_14:12:51/@
ID 443 parent 5 top level 5 path @apt-snapshot-2012-05-02_12:56:59
ID 444 parent 443 top level 5 path @apt-snapshot-2012-05-02_12:56:59/@

[Sanjeev Gupta (ghane)]

Hi,

Please see
  http://www.ogre.com/node/413
for a work-around.

[Andrew Stubbs (ams-codesourcery)]

I came here to report the nested snapshot problem also.

It means the affected snapshots must be deleted manually.

[Martin Cigorraga (martincigorraga)]

I wouldn't tag this bug with a medium priority as in the actual state apt-btrfs is broken and potentially harmful.

But what's really disturbing here is that while this error was reported almost a year ago apt-btrfs is still shipped in its current dangerous state!

I wonder what is Ubuntu/Canonical policy about shipping a broken administrative tool that can potentially disrupt a production environment.

If there isn't a tag-line for a fix apt-btrfs should at least be removed from the official repositories until it is working as expected again, we are talking here about a system-level bug, not a fancy GUI one that could be annoying but doesn't jeopardize user's data.

My 2c...
Regards!

[adrian (addrian20)]

The problem is that aptdaemon invokes dpkg three times, as mentioned in the dpkg manual
http://manpages.ubuntu.com/manpages/trusty/man1/dpkg.1.html
"Note: front-ends might call dpkg several times per invocation, which might run the hooks more times than expected."

My very ugly workaround is to check if any snapshot has been made within the last 60 seconds. I'm attaching my modified /etc/apt/apt.conf.d/80-btrfs-snapshot

[Bram Geron (bgeron)]

This seems to be a duplicate of https://bugs.launchpad.net/ubuntu/+source/apt-btrfs-snapshot/+bug/853849 .

[Rolf Leggewie (r0lf)]

a better workaround is probably to use flock or something like that so that the invocations don't run at the same time. mount already depends on util-linux which provides flock, so that checks out for the dependency question.

[Rolf Leggewie (r0lf)]

@Anybody who can reproduce this

Please change the contents of your file /etc/apt/apt.conf.d/80-btrfs-snapshot to

DPkg::Pre-Invoke {"if [ -x /usr/bin/apt-btrfs-snapshot ] && apt-btrfs-snapshot supported; then flock -w 90 -x /run/apt-btrfs-snapshot.lock apt-btrfs-snapshot snapshot; fi "; };

on a single line and see if that fixes the problem. Apparently, 1 sure way to trigger this is to use update-manager, I believe. You will need to have the util-linux package installed.

[Dark Dragon (darkdragon-001)]

Doesn't flock just create a lock and wait, instead of avoiding multiple snapshots in the first place?

[Rolf Leggewie (r0lf)]

That is what "-w 90" is for.

      -w, --wait, --timeout seconds
              Fail if the lock cannot be acquired within seconds.

Besides, the problem as I see it isn't creation of multiple snapshots per se but the *concurrent* application of multiple snapshots which then end up nested within each other.