Bugzilla – Bug 2052
Mac and Linux: Lock file prevents launching Audacity
Last modified: 2020-03-31 15:00:44 UTC
It would be better for the lock file (Linux and Mac) to be in the /tmp folder so that it is removed on reboot. Current locations: Mac: ~/Library/Application Support/audacity/SessionData Linux: /var/tmp/audacity-<user name>/audacity-lock-<user name> ----------------------------------------------------------------- On Windows our code calls CreateMutex(), which creates a named object in the system processes rather than creating a file, so no file will appear.
We get far too many Mac users getting caught in this unnecessary bear-trap. They end up writing on the Forum "Why does it say Audacity is already running when it clearly isn't" - and then the Forum elves have to spend time digging them out. I turned the tile around to Mac/Linux:... as we saw more Mac users affected by this than Linux users
I added this to the bear-trap page: https://wiki.audacityteam.org/wiki/ToDo:_Unstick_%27Stuck_In_a_Mode%27#Stuck_in_a_Mode
I don't see this problem on Linux. If I crash out of Audacity, I can still see the "audacity-lock-<user-name>" file in /var/tmp/audacity-<user-name>/ but it does not prevent Audacity from being launched. I don't know what Audacity does differently on macOS, but the bug as described appears to be a Mac only issue.
(In reply to Steve Daulton from comment #3) And I recall no postings of this problem from any Linux user on the Forum - so I'll make this Mac only
Raising this to P2 as we get too many users on Mac reporting on the Forum that they are stuck in this bear-trap. This then requires the Forum elves to spend time digging them out. There is an FAQ - but who among users bothers to RTFM ?
And yet another Mac user falls into this bear-trap: https://bugzilla.audacityteam.org/show_bug.cgi?id=2052 We get loads of these - it would be good to fix it
Changing this from ENH to REPEATBLE bug on Mac - we get far too many users reporting this on the Forum - and this wastes a lot of Forum Elves time digging them out. It also looks bad to our users who know perfectly well that they don't have another copy of Audacity running. It does not happen on Windows or Linux - we really should make it not happen on Mac as well.
Promoting this to P1. We get too many Mac users unnecessarily burned by this - they then in confusion write to the Forum - and the Elves then have to spend time hauling them out of the bear-trap.
(In reply to Steve Daulton from comment #3) I can't force this to happen on Mac (macOS 10.14.6) - even if I leave an old lockfile around Audacity 2.3.3, 2.3.2 and eralier versions all still open - so I'm puzzled why this bear-traps some users.
If this helps, I can force it to happen on MacOS IF I change the file attribute to Read Only. Could the issue be that in some cases the user does not have permission for that directory or that file and so Audacity isn't able to delete the file? Currently it appears as if Audacity deletes the file on startup, if the file still exists at that time, because it somehow knows that there is no other copy running. When it can't delete the lockfile that is when Audacity won't start. How that situation comes about I don't know, but I suspect that is the issue. Could a possible fix could be to check if the file is indeed an Audacity Lockfile and then reset the attribute to Read/Write and delete the file if the normal tests show no other copy is running?
(In reply to Cliff Scott from comment #10) I can cause it to happen by setting the lock file to "locked" in "File right click -> Get Info > General". I've not found a way to "automatically" lock the file, but perhaps there is a security setting somewhere that will do that (?)
Testing on macOS 10.14.6 with 2.3.3 alpha jc008 I too confirm Cliff's finding in Comment #10 >I can force it to happen on MacOS IF I change the file attribute to Read Only.
(In reply to Steve Daulton from comment #11) >I've not found a way to "automatically" lock the file, >but perhaps there is a security setting somewhere that will do that (?) In the past Gale maintained that the settings files like audacity.cfg, pluginsettings.cfg etc. could become locked by over-zealous virus protection apps - and that could apply to this lock file I'm thinking
I cahnged the bug title as on the nasis of Cliff's testing (confirmed bt Steve amd myself) it appears that the error only occurs when the lock-file is somehow locked. Thus we may not need to change the location - just fix the locking (and maybe delete the lockfile) and enable the launch.
(In reply to Steve Daulton from comment #11) > I've not found a way to "automatically" lock the file Apparently Mac OS Lion would automatically lock files if they were unchanged for 2 weeks (configurable through Time Machine options down to a minimum of 1 day). This might have been an explanation, except that this "feature" was removed in later versions of Mac OS, and we have reports of this problem much later than MacOS 10.7. Although we don't yet know if the problem is due to file permissions, file locking, or some other reason, as this bug is P1, perhaps Audacity should check if the lock file is locked or read only, then either fix (unlock) the file, or failing that, give an error message so that Audacity developers know what is causing this bug.
Extra dialog now pops up in this special case of lock file exists and yet cannot connect to Audacity, asking user if they want to delete the lock file. https://github.com/audacity/audacity/commit/98f495a4858b98198f66f4c956fb4730bf13a390 This is not a fix for the problem, if the problem really is that the file is read only, but it does give us more of a handle as to what is going on. Hence I think we can reduce this bug to P2.
Testing the latest change on MacOS 10.14.6 with a read-only lock file. I find that a dialog comes up saying "unable to lock the temporary directory" as well as saying another copy of Audacity may be running and beware it may cause issues if another copy is started. It doesn't say it is going to try to delete the lock file. Responding with a yes to launch anyway launches Audacity, but the main Audacity window is not visable unless the user clicks the icon/listing in Applications or the Launch bar again. The user will not know to do that in most cases so will think there is a zombie process running. I was able to start multiple copies of Audacity this way. IMHO, the main window should be launched so the user will be able to use it. Starting with a read/write lock file the lock file is deleted and a new one generated and Audacity launches normally.
(In reply to James Crook from comment #16) Testing with macOS 10.14.6 with 2.3.3 alpha jcoo9 of 03Oct19 I get an error message which says (messy layout as it appears on-screen) >Audacity is already running >The system has detected that another copy of >Audacity is running >Running two copies of Audacity simultaneously >may cause >data loss or cause your system to crash > >Use the New or Open commands in the currently >running Audacity >process to open multiple projects simultaneously Clicking the OK button steps to a second error message >Possible Lock File Problem >If you're sure another copy of Audacity isn't >running, Audacity >can skip the test for "Audacity already running" >next time >by removing the lock file > >/Users/petersampson/Library/Application/Support >audacity/SessionData/audacity-lock-petersampson > >Do you want to do that? (this is also an untidy text layout) Clicking "Yes" failed to delete my locked Lock File - and relaunching Audacity takes me through the same pair of error messages again (and again …) This is perhaps worse than before as we now have not one, but two confusing messages - and we still can't launch Audacity
Further testing shows that it does remove the Lock File if it is unlocked - but NOT if the Lock File is locked
Testing on macOS 10.14.6 with 2.3.3 alpha jc010 Reducing to P2 as ther is now an additional error message that tells the user where the Lock File is located. It does try to delete the Lock File too - but this only works if the Lock File is un-locked. So this must remain open at P2
This problem does not usually occur on Linux, but occasionally it can. To reproduce the issue on Linux: 1) Launch Audacity 2) Make a copy of the lock file 3) Close Audacity 4) Rename the copy of the lock file so that it is a valid lock file 5) In a Hex editor, change contents to the PID of a running process, terminated by NULL (00). 6) Attempt to launch Audacity. 7) Audacity fails to launch and throws an error saying that Audacity is already running. This can happen "naturally" if Audacity crashes (leaving the lock file in place) and then another application is started that (by chance) has the same PID that Audacity previously had. This issue could be avoided (in Linux) if Audacity checked not only that the PID is in use, but also that the Application name of the process with that PID is "Audacity".
I've marked thsi as "quickfix requested" as we keep getting user posting on the Forum who are stuck in this nice little bear-trap = with no idea how to eacape ...
I am raising this to P1 for a couple of reasons: 1) we are now getting reports of this on Linux, 2) we get far too frequent reports on the Forum and Facebook pages of users who are stuck in this bear-tap with no cognizance of how to escape (the escape route is far from "discoverable").
(In reply to Peter Sampson from comment #23) Aren't there duplicates of this problem? I recall examining similar bug issues and deciding that there was actually a bug in wxWidgets that might require us to make new patches. At the time, I was reluctant to pursue that for 2.3.3.
I recall examining this problem and deciding that there was actually a bug in wxWidgets that might require us to make new patches. At the time, I was reluctant to pursue that for 2.3.3.
I worked on this over the weekend and have two possible solutions. Both target the non-Windows handling since I believe Windows handling is fine as-is. The first solution simplifies the "file-based" by getting rid of the lock file entirely by utilizing the socket file for detecting if Audacity has failed or is active. It's still file based which leaves it vulnerable to all those weird permission, virus checker, etc, but I don't know if that's a big concern. The second solution is a bit more complicated than solution 1, but it gets rid of both files entirely. It uses sockets like solution 1, but instead of Unix domain sockets, it uses plain old IP sockets. It uses random port assignment, so stores that port in shared memory. That way the simultaneous executions can pass that command line filenames to the already executing Audacity. I'm still working on the second solution and am nearly done. When I'm done, I'd like to be able to provide both solutions for testing and I'm probably going to come up with some hackage to allow you guys to select which to use somehow.
Actually, I'm just going to provide solution #1 since it's much easier to understand and keep solution #2 in my back pocket in case #1 doesn't make it past y'alls testing. :-)
Okay, "fix" committed in: https://github.com/audacity/audacity/commit/bd04315 This will require extensive testing on Mac and Linux. I've done a fair amount on my end, but since I'm the "changer" I've may have missed some scenarios. Also, even though this is for a Mac/Linux issue, it should also be tested on Windows since the Mac/Linux code was extracted and separated from the Windows code and bugs could have been introduced. (Likelihood is low though.)
One area of concern is that this is incompatible with all prior versions. So, if a person tries to start v2.3.3 and v2.4.0, it will work...both will start. I've pondered checking for the existence of the lockfile in the new method and simply refusing to start (with dialog) about running 2.4.0 and (possibly) 2.3.3 or older together. What do y'all think? Is it important?
(In reply to Leland Lucius from comment #28) Tested on macOS 10.15.3 with Audacity 2.4.0 1174875 1) I can no longer cause 2.4.0 to get locked-out on Mac by Force quitting - and I tried several times. 2) I can no longer force a lock-out by following the Steps to reproduce, as 2.4.0 no longer writes a lock file in ~/Library/Application Support/audacity/SessionData 3) I do not know if there is now an alternative lock file that may, or may not, cause a similar problem. 4) I tested the following steps a) launch 2.3.3 b) Force Quit c) lock the Lock fil in ~/Library/Application Support/audacity/SessionData d) attempt o launch 2.3.3 e) Observe: fails with "Audacity already running" message (expected behavior) f) launch 2.4.0 g) Observe 2.4.0 launches - ignoring the locked lockfile in ~/Library/Application Support/audacity/SessionData So for me it looks as though this is probably fixed on Mac - but I plan to keep a watching brief on this and will endeavour to use Force Quit whenever I need to close Audacity in my testing. I will do similar on Windows
(In reply to Leland Lucius from comment #29) >One area of concern is that this is incompatible with all prior versions. >So, if a person tries to start v2.3.3 and v2.4.0, it will work... >both will start. I can't seem to make this happen >I've pondered checking for the existence of the lockfile in the new method and >simply refusing to start (with dialog) about running 2.4.0 and (possibly) >2.3.3 or older together. > >What do y'all think? Is it important? Looks like another component for the Multi-Project Wormcan: https://wiki.audacityteam.org/wiki/The_Multiproject_Wormcan
(In reply to Leland Lucius from comment #28) Tested on W10 with Audacity 2.4.0 1174875 I cannot get locked-out by force crashing Audacity using the Task Manager - Audacity launches and Recovery kicks in nicely.
Testing on Linux, the new ".audacity.sock" looks good. While .audacity.sock exists and Audacity is running, it is impossible to start another Audacity session. If Audacity is forcibly killed, leaving the .audacity.sock behind, Audacity may be restarted, though there is about a 6 second delay before Audacity starts visibly launching (nothing reported in the terminal for about 6 seconds). If an older version of Audacity is running (I tested with 2.3.3), then Audacity 2.4.0 cannot be launched. If Audacity 2.4.0 is running, then Audacity 2.3.3 CAN be launched. Leland wrote in comment #29 > One area of concern is that this is incompatible with all prior versions. > So, if a person tries to start v2.3.3 and v2.4.0, it will work... > both will start. I can confirm that this occurs if v2.4.0 is launched first, but not the other way round. > What do y'all think? Is it important? It's clearly not easy to do this "accidentally". I don't see anything bad happening when running two versions, though I've not tested extensively. We certainly should not advertise the fact that this is possible unless we decide to make it a feature, and do very extensive testing. If we mention it at all in the 2.4.0 manual, it should just be to say to not do it (although saying that will no doubt encourage some to try). I think this limitation is acceptable, but if not, then we would need to take a different approach (such as checking that the PID in the lock file is a currently running process with command name "audacity").
(In reply to Steve Daulton from comment #33) > Testing on Linux, the new ".audacity.sock" looks good. > > While .audacity.sock exists and Audacity is running, it is impossible to > start another Audacity session. > > If Audacity is forcibly killed, leaving the .audacity.sock behind, Audacity > may be restarted, though there is about a 6 second delay before Audacity > starts visibly launching (nothing reported in the terminal for about 6 > seconds). I could certainly print a message to the terminal stating the communication with an already running Audacity was being attempted. But, that would only be seen by command line users, so it's usefulness might be a bit suspect. And you are correct, it attempts to connect to an existing Audacity 50 times with 100 millisecond pauses between. Honestly, that's WAY overkill. It really only needs to be about 1 second. That's plenty of time for Audacity to get up enough for another one to talk to it.
(In reply to Leland Lucius from comment #34) > I could certainly print a message to the terminal... ... > it attempts to connect to an existing Audacity 50 times with 100 millisecond > pauses between. Honestly, that's WAY overkill. > It really only needs to be about 1 second. That's plenty of time for > Audacity to get up enough for another one to talk to it. I think reducing the time-out would be better than adding a message, though a message in the terminal could be informative for a few users and would do no harm. Could you reduce the overkill a bit while keeping it safe (20 times with 100 ms delay?) and add a message to the terminal? I don't think anyone will be concerned by the launch taking a couple of seconds longer after an improper shutdown.
(In reply to Steve Daulton from comment #35) > (In reply to Leland Lucius from comment #34) > > I could certainly print a message to the terminal... > ... > > it attempts to connect to an existing Audacity 50 times with 100 millisecond > > pauses between. Honestly, that's WAY overkill. > > It really only needs to be about 1 second. That's plenty of time for > > Audacity to get up enough for another one to talk to it. > > I think reducing the time-out would be better than adding a message, though > a message in the terminal could be informative for a few users and would do > no harm. > > Could you reduce the overkill a bit while keeping it safe (20 times with 100 > ms delay?) and add a message to the terminal? I don't think anyone will be > concerned by the launch taking a couple of seconds longer after an improper > shutdown. Done. 2 seconds with the following console message: Attempting to connect to Audacity failed...retrying
On the basis that this works on Widows and Mac - and the fix was provided by Leland) who works on Linux) I am going to trust Leland's fix (I trust his thoroughness in testing before releasing his fix) I am going to close it as RESOLVED. The Linux element of this is different to the Mac bug (far less occurrent) - this was originally logged a a Mac big (the Linux bit was tacked-on later). If need be we can always open a new Linux-only bug for this
(In reply to Peter Sampson from comment #37) For completeness, I've retested on Linux after Leland's comment 36 change, and all looks good, no "residual" issues.
