Hello forums, I just tried to install and run the latest Audacity on a MacBook Pro running Os X 10.8.5 when logged in as a network user, the application pops up in the dock and then immediately shuts down. The log shows
2015-03-30 11:54:55,977 com.apple.launchd.peruser.1081[272]: ([0x0-0x398398].net.sourceforge.audacity[42865]) Exited with code: 255
I then made the same account to a Mobile account in Workgroup manager, tried the same thing and the app started without a problem, showing first a dialog with a list of plugins. (Works just as well with a local account)
This has never happened to me before with any version as far back as 1.3.x.
Anyone else using Audacity in combination with network accounts? Might be a problem when accessing some resource through a network path?
Audacity has no official support for OS X Server if that is what you have - it amounts to (and previously was) a separate operating system, as far as I can see.
What OS’es are these other network computers on?
How would you define the difference between a “network user”, “mobile account” and “local account”?
Please feel free to provide a Mac Crash Report. On a standard OS X 10.8 system this would be at ~/Library/Logs/DiagnosticReports/. However it is highly unlikely we could reproduce the issue without step by step instructions to set up the same environment as you.
The problem occurs on clients running standard OS X installations (10.8.5 like stated above), but with accounts hosted on an OS X server (Snow Leopard, 10.6.8 which was the last version released as a separate server OS AFAIK. From Lion and up you run the Server app/Workgroup manager in regular OS X to get server functionality).
Network account: the user home is never present physically on the local hd, all data is shuffled in real time between client and the server through afp
Mobile account: the user home is synced from the server to the client at login and logout (and during sessions if configured so)
Local account: account with no user home data linked to the server in any way
The crash occurs so early that no diagnostic crash report is created, the log entry in the first post is the only clue.
Even though Audacity lacks official support for OS X server or running on clients with server managed accounts, it has like I said worked without any problem before 2.1.0 and it would be unfortunate to leave it like this.
Steps to (hopefully) recreate:
-Setup any OS X server - client environment, if possible, the same as me, OS X Server 10.6.8 and clients 10.8.5.
-Create a network account with Workgroup manager
-Install Audacity on the client, either as a local admin or as network user, it does not seem to matter
-Log in with the network account
-Launch Audacity
If you mean upgrade our server to Mountain lion, then yes, we are thinking about it even though the Server App in ML is quite inferior to the Server Admin that is only supported in Snow Leopard. All our clients are running ML or above so the accounts themselves are ML if you can put that kind of label on an account.
These tests were performed on a fresh account, no old audacity prefs were present to begin with.
To be sure you have fresh preferences for each test you need to delete audacity.cfg before each launch of 2.1.0 or trim audacity.cfg to “NewPrefsInitialized=1” before each launch of 2.0.6.
As expected, the 2.1.0 .cfg does not get to load audio devices. Was there a way to turn off network transmission of audio to see if 2.1.0 launched then with a network account?
One change in 2.1.0 that might be relevant is that audio device names are translated if the language set in the Mac’s System Preferences is other than English. So you could try changing system language to English either on the client or the server depending from where Audacity determines the system language. Reboot the machine where you make the language change.
To be clear, I won’t be looking at this. I only have one Mac and even if this could be reproduced with VM’s, Audacity does not officially support client/server relationships or server OS’es.
When I have all the information I can think of asking you for, I’ll let a Mac developer know and we’ll see what happens.
Absolutely, the preferences were deleted between the test with 2.1.0 and the file was blanked and “newprefs…” inserted before installing 2.0.6
I’m not sure what you mean by “network transmission of audio”? I do have the Jack framework and plug-in installed on this machine but not on the other that we have tested with the same bad results.
I’ve tested with both Swedish and English as both account language (through system preferences) and system language (with the terminal command) but no improvement.
RDP and other protocols used on Windows let you choose to send audio over the network or not.
I know nothing of OS X Server but it seems like your failure may be occurring when audio devices are queried and turning off audio transmission might have helped confirm that.
Where is Audacity.app in that scenario - on the remote machine?
Thanks for testing. I’ll see if Leland (our Mac developer) has any ideas about this.
Unfortunately, I don’t have access to an OSX server to test with but seeing what you wind up with in audacity.cfg and the fact that this has worked until 2.1.0 suggests it is the creation of the socket file in the application support directory:
Gale, I think that we might have been misunderstanding eachother on some details. There is no audio transmission over the network happening in the scenarios above, we’re not using our server as a terminal server or letting it do any audio processing. Audacity is always run from the local drive, all processes are loaded into local memory, audio played from the local sound card and as you can see above, the temp folder is also located on the local drive. When logged in to a network account only the user data (“~/username” to clarify), like the Audacity preferences, is stored and accessed through the network (that’s a half lie, but it’s a good enough explanation).
Leland, I will check this out after the Easter holidays, but I have no memory at all seeing an .audacity.sock file in “application support/audacity” on my regular (working) mobile account, which is configured to show hidden files.
A quick google shows no sign that SL-Server wouldn’t support sock files. My knowledge about them is very limited though, this is the first time I’m made aware that they exist.
only the user data (“~/username” to clarify), like the Audacity preferences, is stored and accessed through the network
Without getting down to the fine details, Audacity doesn’t understand network delays and management (yet). If it needs to access any part of the application over the network then that portion becomes subject to critical timing. It’s possible you got lucky with the other version.
You would search for Unix domain sockets. They are for IPC between processes running on the same machine. I’ll also poke around to see if I can get a definitive answer.
I couldn’t find a definitive answer, so I tested it myself. While I don’t have OSX Server, what I try to pass off for a brain kicked in and I realized that I can do AFP sharing between two clients…DOH!
Anyway, as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.
I don’t see a workaround for you unless you want me to build you a private version that relocated the socket file to the users “temp” directory. I assume that would be on the local filesystem???
As I understood it, the original plan was to put the socket file in the user’s temp directory http://bugzilla.audacityteam.org/show_bug.cgi?id=202#c13 . Did we change that because we’re planning to move the lock file into Audacity’s configuration directory?
At the time, the only reason for doing so was so that it would be as easily usable by other users. The Audacity data directory did the same thing, but we now know that there’s a more concrete reason to put the socket file in the user specific temp directory.
So if we don’t need the socket file to be in the same directory as the lock file, it seems we should actually go back to putting the socket file in the user specific temp directory.
I “think” TwinOak is saying that the chosen Audacity temp folder is actually on the local computer and not being read over the network. But if it was chosen to put the Audacity temp folder where the ~/username is (on the network, as I understand it) then it would presumably still fail.
To answer the question and clarify: we do not change the setting for the temp folder so it gets created in the default location on the local drive in all scenarios above.
I’m very impressed and grateful that you’re taking the time, thanks a bunch!
Alexander
