Audacity Forum

Leland wrote:

Gale Andrews wrote:

Leland wrote:

Lesa wrote:Hi Gale! I just did a huge sweep of files on my computer and fixed it. Not exactly sure what happened but I repeated the steps you gave me and it worked after posting my last message. solved! Thank you!!

Lesa, did you clean up the files listed above? Specifically, did you delete the "audacity-lesawilson" directory or its contents? That is where the "single instance" lock file is located and is what I was going to suggest you delete to fix the problem.

I wondered about that, because I recalled a left over lock file from an old session could cause "already running".

But I'm not seeing a left over lock file causing that message on Mavericks or Yosemite, if I fake it by copying the lock file to somewhere else, quit Audacity, paste the lock file to Audacity's temp folder in /var/folders then launch Audacity. Audacity just starts anyway.

However I can't start a second instance of Audacity running except in the known cases.

I see the same on Linux Ubuntu - a pasted lock file does not stop Audacity 2.1.0 launching. A pasted lock file makes Audacity 2.0.4 give a warning about unable to lock the temporary folder because it may be in use by another copy of Audacity, but if I OK the warning I can launch Audacity.

What should happen?

In 2.0.4, an existing lockfile at startup would cause the "already running" message on OSX and Linux if there was a problem trying to read the existing lockfile (this is all wxWidgets at this point). The file is supposed to be read to retrieve the PID of the owning process and a check is made to see if that process is still running. Somewhere in there a failure is happening and I'd need to trace through wxWidgets to figure out why.

Sorry, Leland I'm not sure I understand. Are you saying that the user "should" be seeing "Already running" if they force quit and restart if things worked as expected?

If the normally created lock file contains the PID of the Audacity version that starts, then naturally I would not be surprised if Audacity starting after a force quit had some other PID. Are we checking for the existence of a lock file or for a matching PID?

Leland wrote:

Gale Andrews wrote:

Leland wrote:The $TMPDIR folder is usually cleaned up at each reboot, so I'm curious why yours had some many items of significant age. Do you normally not shutdown your machine? Do you always just let is "sleep"?

If so that could raise another issue, because on Linux we changed the default location of the Audacity temporary directory to be in /var/tmp instead of /tmp, on the grounds of preserving the directory between reboots.

Is there a Mac temp location that is preserved between reboots?

We're going to be changing it post 2.1.0 to the project directory, so it should survive reboots.

I understand we're going to move the lock file to ~/Library/Application Support/audacity/ (where the *.cfg files are kept). Is the Audacity temp folder moving there too?


Gale

FWIW: My 2.0.6 on Yosemite (which, yes, I know I'm not supposed to be running here) not only noticed that lock file, but gets caught in a requires-force-quit loop if it finds one; the splash screen is overtop the dialog, and you *can't* OK it. Just a datapoint.t

Baylink wrote:FWIW: My 2.0.6 on Yosemite (which, yes, I know I'm not supposed to be running here) not only noticed that lock file, but gets caught in a requires-force-quit loop if it finds one; the splash screen is overtop the dialog, and you *can't* OK it. Just a datapoint.t

So are you saying that you tried to launch Audacity and got "Audacity is already running"?

Did you quit Audacity normally the last time you quit? Did you see an error when closing that it could not remove the lock file?

I have some recollection that there were problems when we've tried to locate the splash screen away from centre.

Gale

Gale Andrews wrote: Sorry, Leland I'm not sure I understand. Are you saying that the user "should" be seeing "Already running" if they force quit and restart if things worked as expected?

Not necessarily. If there's an existing lock file and wxWidgets is able to read the PID from it, then wxWidgets is "supposed" to check to see if the PID is still active and if not, it figure the lock file is stale and tries to clean it up. In that case, Audacity should start up fine. But, it seems that's not always working and, as mentioned, I'd need trace through the wxWidgets codes to figure out exactly what's happening. I'd rather wait to do that after the post-2.1.0 rework.

Gale Andrews wrote:If the normally created lock file contains the PID of the Audacity version that starts, then naturally I would not be surprised if Audacity starting after a force quit had some other PID. Are we checking for the existence of a lock file or for a matching PID?

wxWidgets is the one doing the checking and it checks for the existence of the file and, if so, retrieves the PID from the file and checks to see if it is still running.

Gale Andrews wrote: I understand we're going to move the lock file to ~/Library/Application Support/audacity/ (where the *.cfg files are kept). Is the Audacity temp folder moving there too?

No, the temp folder wasn't going to move, but I do see where you're going with that. It might be more appropriate to change the temp folder to "~/Library/Caches/TemporaryItems/" or maybe /var/tmp. (I'd prefer the former though)

Leland

Leland wrote:

Gale Andrews wrote: Sorry, Leland I'm not sure I understand. Are you saying that the user "should" be seeing "Already running" if they force quit and restart if things worked as expected?

Not necessarily. If there's an existing lock file and wxWidgets is able to read the PID from it, then wxWidgets is "supposed" to check to see if the PID is still active and if not, it figure the lock file is stale and tries to clean it up. In that case, Audacity should start up fine. But, it seems that's not always working and, as mentioned, I'd need trace through the wxWidgets codes to figure out exactly what's happening. I'd rather wait to do that after the post-2.1.0 rework.

OK that's clear, thanks Leland. If I do the test quitting Audacity then paste an old lock file and launch Audacity, I can see the old lock file get deleted and a new one added.

Leland wrote:

Gale Andrews wrote: I understand we're going to move the lock file to ~/Library/Application Support/audacity/ (where the *.cfg files are kept). Is the Audacity temp folder moving there too?

No, the temp folder wasn't going to move, but I do see where you're going with that. It might be more appropriate to change the temp folder to "~/Library/Caches/TemporaryItems/" or maybe /var/tmp. (I'd prefer the former though)

I would prefer either of those to Audacity's folder for application data. Why would you prefer user space for the Audacity temp folder on Mac, but not on Linux?

Just now I force quit Audacity then rebooted the Mac to test if I could recover the temporary project, and I could not - the project folder is deleted. But not so long ago I pulled the plug on the Mac and recovered the temporary project. Might that mean Mac would not do the clean up of the temp folder unless it shut down properly?

Either way, we really shouldn't store the Audacity temp folder where reboot wipes it.


Gale