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 Kristian (klausenbusk) - Saturday, 03 June 2023, 18:04 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
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

Closed by  Kristian (klausenbusk)
Saturday, 03 June 2023, 18:04 GMT
Reason for closing:  Upstream
Additional comments about closing:  Please report upstream if still relevant: https://gitlab.archlinux.org/archlinux/d evtools.
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!
Comment by freswa (frederik) - Wednesday, 12 February 2020, 12:18 GMT
Is this issue still present?

Loading...