Solved C4D R21 does not run on macOS within deamon any more

Hi

I already contacted support about the issue and they told be to use the SDK forum to get in contact with the development team about this issue. The issue is that R21 cannot be used any more within a background deamon(service) on macOS. One of our customers just switched to R21 for their upcoming project and they got into that issue.

If you need help to reproduce the issue or a test machine (teamviewer) to test something, please let me know.
Or if you have any test application/ test version you would like me to run, let me know as well.
Perhaps a version that prints every step helps you to find the location/module that is responsible.
E.g. Loading module "asdsdas" now, Initializing "asdsdsa".

About running as background deamon(service):
Many companies require security rules like that everyone has to logout if they leave or that the user logged-in is not allowed to access all projects that the render farm can access. Therefore the render farm has to run as background service/deamon. I was already told by support "I would not be aware that our software can even be used without a logged-in user". BUT: Even if you have not tested it, companies use it and HAVE TO use it.

I can not tell you the exact issue why R21 does not run, I have just collected some issues I found.
BUT: these errors have been printed by R20 as well, but R20 rendered anyway.

Issue 1:
The last message that is printed is "LLVM Profile Error: Failed to write file 'default.profraw': Permission denied".
R20 prints the same message when the app is closed (after the render).
There is an other issue with the file as well, customers report that these files are big and if you use Arnold, they are saved beside the scene. Solidangle (Arnold renderer) has already told me that the issue of that file is in the C4D python lib: "The default.profraw file is created in the current working directory when Cinema 4D starts and written when Cinema 4D closes."

Issue 2:
If the mac was restarted and nobody ever logged in, then the last error is
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
2020-02-06 15:08:36.947 Commandline[477:3391] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'ClientCallsAuxiliary': Connection interrupted

Issue 3:
The Commandline app tries to load many libs that require an UI. Shouldn't the Commandline app be able to run without UI libs? It prints about 150.000 bytes of warning messages each time started.
Examples:
net.maxon.gui: Initialization of mac_clipboard.mm [initialization] failed.
net.maxon.drawport_opengl:....
net.maxon.c4d.c4dplugin: paint_tooltransrect.cpp
net.maxon.mvp_base_presenter: presenter_base_impl.cpp
net.maxon.mvp_base_view: widget_base_impl.cpp
net.maxon.mvp_desktop2d_widgets
net.maxon.c4d.nbp: nimbus_impl.cpp could not be initialized because net.maxon.interface.amemulation is missing.
net.maxon.c4d.nodeeditor_material: could not be initialized because net.maxon.mvp.windowclasses.base is missing.

Hi @hSchoenberger, thanks for reaching out us.

With regard to the issue reported, we're investigating something similar on Windows as well.

To reproduce the issue, can you please provide more details on how the customer is running Cinema as a daemon?

• what app is tried to run as a daemon? is TR client? is CommandLineRenderer? And if is CommandLineRender what's the scope to run it as a daemon?
• what macOS procedure is he using? launchctl utility ? Is yes, can you provide the .plist file and a description of the procedure used to create such daemon?
• Are you sure that the customer has validated his credentials - basically he has run the executable in standard mode at least once to get him signed in with his MAXON ID account - before running the apps as daemons?

Looking forward hearing from you, give best.

Hi @hSchoenberger, thanks for reaching out us.

With regard to the issue reported, we're investigating something similar on Windows as well.

To reproduce the issue, can you please provide more details on how the customer is running Cinema as a daemon?

• what app is tried to run as a daemon? is TR client? is CommandLineRenderer? And if is CommandLineRender what's the scope to run it as a daemon?
• what macOS procedure is he using? launchctl utility ? Is yes, can you provide the .plist file and a description of the procedure used to create such daemon?
• Are you sure that the customer has validated his credentials - basically he has run the executable in standard mode at least once to get him signed in with his MAXON ID account - before running the apps as daemons?

Looking forward hearing from you, give best.

@r_gigante

Hi

Windows:
So far we do not see any issue on Windows. Perhaps ther is a difference in the service environment compared to your test environment. Our service tells Windows to load a users environment (Registry, C:\Users...)
There is an openGL error message, but it has no effect:

Could not initialize OpenGL root context: unsupportedoperation [ogl_context_win.cpp(1176)]

Licensing:
A customer had that issue some time ago and their error message was clear about the missing license setup.
I have set g_licenseusername and g_licensepassword In my test environment.
If I block Commandline from accessing the Internet on Windows via a firewall, I get a license error message as well.
I have tested to use a wrong g_licensepassword. Windows reports "Invalid License".
OSX does not get to that part, same behavior as usual.

Daemon:
Our render manager Royal Render handles the daemon part and then starts a shell script with the C4D commandline executable. File /Library/LaunchDaemons/de.BinaryAlchemy.plist attached:de.BinaryAlchemy.rrAutostartservice.plist.txt

I have some render logs.
Note: If a line starts with "StdErr:", then your app printed it into the StdErr insted of StdLog. StdErr and StdLog might be a bit async due to the systems log pipe.
Mac just started, no user logged in: WindowServer_NeverInitialized.txt
User logged in:
WindowServer_LoggedIn.txt

PS:
I can provide you a simple Daemon that just executes a shell script over and over without all the other files that Royal Render uses. The deamon has its own installer included (for the /Library/LaunchDaemons/de.BinaryAlchemy.plist file).
OSX and Windows.

Or a full RR demo that gives you more control about when to start a render commandline and it saves render log files for each render. Or you can use our test machine via teamviewer.

@r_gigante
PS: Remember that R20 has the same error messages, but still renders.
It is an issue that does not print any error messsage, but calls an exit(0) or a return(0) in your main.cpp.
(No error code used in return() or exit())

OR: It prints it, but a flush command is missing after the last print command.
And closing the app might loose the log buffer that was not yet transfered to the systems log pipe.
(We had that issue with Maya crashes, the last lines of the stack trace Maya prints had been missing)

Regarding issue 1 (default.profraw): I got the same error message "Failed to write file 'default.profraw': Permission denied" when running c4dpy (Cinema 4D's own Python interpreter) for the first time. The file "default.profraw" is related to Xcode (Apple's IDE) and has something to do with the testing/debugging/profiling phase of program development.

My guess is, that in some parts of Cinema 4D, a debugging or profiling flag has been left "on" by mistake, and that's why the app (or some part of it) is trying to create this particular file "default.profraw". In my case, c4dpy was trying to create it in the main Cinema 4D directory, which is (by default) owned by root, and write-protected. When I changed the directory access rights (removed write-protection), the error message disappeared, but now a "default.profraw" appears in the Cinema 4D folder whenever I run c4dpy.

I have no idea if all this is general knowledge, or just a shot in the dark... hope it helps you guys...

HeiLei

Hi

Issue 1 (default.profraw file):
Yes, it is a compiler settings. The setting was set in R20 as well, the setting was probably never checked/noticed since the affected module was created.
The Solidangle developer has fixed the issue in Arnold4C4D by "My workaround is to look for and remove the file from cwd in PluginStart() and change cwd to /var/tmp on PluginEnd(). This means the file is not in the folder where C4D was started from nor the project folder, only in /var/tmp which is acceptable."
Which means that if I "cd /var/tmp" before starting C4D, the message should be gone.
I have not yet tested it as R20 has the same issue and still renders.

Any update?