identification to need to setup pidlock worked fine in the past
e.g. here with 7.20181105+git22-g4c7236c58-1~ndall+1
[bids@rolando BIDS] > mkdir d; cd d; git init; git annex init; cat .git/config
Initialized empty Git repository in /inbox/BIDS/d/.git/
init
Detected a filesystem without POSIX fcntl lock support.
Enabling annex.pidlock.
ok
(recording state in git...)
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[annex]
uuid = 718ca7cc-e0ee-49d9-9bac-37b77e44a20b
pidlock = true
version = 5
[bids@rolando d] > git annex version
git-annex version: 7.20181105+git22-g4c7236c58-1~ndall+1
but I saw it starting to fail with some upgrade and ignored too long to report:
bids@rolando:/inbox/BIDS$ mkdir d; cd d; git init; PATH=/home/bids/singularity_home/git-annex/7.20190731-gbb16a2610/:$PATH git annex init; cat .git/config
Initialized empty Git repository in /inbox/BIDS/d/.git/
init
git-annex: waitToSetLock: resource exhausted (No locks available)
failed
git-annex: init: 1 failed
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[annex]
uuid = 5183b554-a0a3-4363-9541-53ca5673ddae
bids@rolando:/inbox/BIDS/d$ PATH=/home/bids/singularity_home/git-annex/7.20190731-gbb16a2610/:$PATH git annex version
git-annex version: 7.20190731-gbb16a2610
build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
operating system: linux x86_64
supported repository versions: 5 7
upgrade supported from repository versions: 0 1 2 3 4 5 6
mount point details:
type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.232.11.5,mountvers=3,mountport=680,mountproto=udp,local_lock=none,addr=10.232.11.5)
No changes in the code of the lock test. Somehow the exception was not caught, and it's only catching IO exceptions, so it must be another type of exception.
Oddly, I can't find any indication that waitToSetLock can throw anything other than an IO exception.
I've changed it to catch all exceptions, which will presumably fix the problem, but not closing this bug as I don't fully understand it and so am not certian of the fix.
I have ran git bisect, didn't double check but it points to
may be that gives ideas? (build env was the same, freshly regenerated buster singularity image available via
singularity pull shub://datalad/datalad:git-annex-devFWIW, the issue persists with current version in master (which comes after comment from 3 days ago where wider exception catching was told to be implemented):
Thanks for the bisection. It's not the init code that's trying and failing to set a lock, but the misctmp cleanup code. Which is ironically now used in setting up the temp directory that init uses to probe for locking problems. Chicken and egg problem.
Committed a fix.