Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#25658 - [devtools] move .lock files generated by mkarchroot and makechrootpkg to /run or some other place

Attached to Project: Arch Linux
Opened by Auguste Pop (Auguste) - Thursday, 18 August 2011, 22:21 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 13 May 2015, 20:13 GMT
Task Type Feature Request
Category Arch Projects
Status Assigned
Assigned To Pierre Schmitz (Pierre)
Dave Reisner (falconindy)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

Details

Description:
those .lock files do not have to be named after the directory and put alongside it. we may give a static name for every fd we use.

Additional info:
* package version(s)
git HEAD
* config and/or log files etc.


Steps to reproduce:
run mkarchroot or makechrootpkg
This task depends upon

Comment by Lukas Fleischer (lfleischer) - Friday, 26 August 2011, 07:40 GMT
I agree that the current location isn't the best place for lock files. There are two issues we should consider more carefully before moving them to "/var/lock" or "/run/lock" though:

* Naming and format of lock files: We should be able to distinguish between different chroots. It should still be possible to run several instances of makechrootpkg simultaneously if they do not use the same chroot directory.

* NFS shares: As usual, the lock file mechanism will break if a chroot directory is shared (e.g. via NFS).
Comment by Dan McGee (toofishes) - Friday, 23 September 2011, 22:26 GMT
Why don't you put them in /var/lock *inside* the chroot?
Comment by Lukas Fleischer (lfleischer) - Friday, 07 October 2011, 08:25 GMT
While it might be not the semantically best location, it's probably the best thing we can do here, yeah... Good idea!

Loading...