Solved Cinema 4D Client R21 Service Creation

Now firstly, i know this isn't plugin or development related. Apologies, but hear me out...

The reason for asking on this forum is due to the fact that the answer to the question is likely to be weighted more to a development team than a general support query (I have tried the latter and it fell on deaf ears and i was told this would likely be dealt with by a development team.

At this point i thought it wouldn't hurt explaining my use case to see whether anyone could shed some light, on any breaking changes to R21 that make have stopped this functionality working. (Disclaimer: I'm fully aware that it's an unsupported way of running the render client)

We have around 30 nodes, And historically I've successfully managed to run R18/R19 as a service - And it's been super handy.

We never used R20 so i can't vouch for it, but we recently jumped to R21 and for some reason i just can't get the R21 client working as a service. I've historically used nssm.exe (non-sucking-service-manager) to wrap the exe as a service and it's worked great. But development seems to have broken the compatibility of running the client in this manner. I'm not getting any real clues in the logs and the only messages in the error output log of the client references the following:

WARNING: Error loading file:///C:/Program Files/Maxon Cinema 4D R21/plugins/TurbulenceFD_C4D_v1-0_1452/TurbulenceFD_R20_1452.xdl64: symbol 'g_maxon' is missing. [win_dll.cpp(393)] [general.cpp(386)]
Loading file:///C:/Program Files/Maxon Cinema 4D R21/plugins/TurbulenceFD_C4D_v1-0_1452/TurbulenceFD_R21_1452.xdl64 with module(s) com.jawset.turbulencefd
Loading file:///C:/Program Files/Maxon Cinema 4D R21/corelibs/uvviewport.xdl64 with module(s) net.maxon.c4d.uvviewport
Loading file:///C:/Program Files/Maxon Cinema 4D R21/corelibs/volumes.xdl64 with module(s) net.maxon.c4d.volumes
Loading file:///C:/Program Files/Maxon Cinema 4D R21/corelibs/walkthrough.xdl64 with module(s) net.maxon.c4d.walkthrough
WARNING: Error loading file:///C:/Program Files/Maxon Cinema 4D R21/plugins/X-Particles_732/X-Particles.xdl64: symbol 'g_maxon' is missing. [win_dll.cpp(393)] [general.cpp(386)]
Loading file:///C:/Program Files/Maxon Cinema 4D R21/plugins/X-Particles_732/X-Particles_21.xdl64 with module(s) ltd.insydium.xparticles
Loading file:///C:/Program Files/Maxon Cinema 4D R21/corelibs/xpressocore.xdl64 with module(s) net.maxon.c4d.xpressocore
Loading file:///C:/Program Files/Maxon Cinema 4D R21/corelibs/xtensions.xdl64 with module(s) net.maxon.c4d.xtensions
Could not load dll. (relative:///opencl.dll) [win_dll.cpp(319)] 

I believe the opencl.dll winge is a red herring as R19 shows the same in the logs but has worked flawlessly for us as we just use CPU based rendering.
Have any paths changed or are there any known dependencies or variables that the service may need to be aware of to run the render client?

Is there anything i can do to get a more verbose log?

For what it's worth i can't even find a reference of win_dll.cpp existing!

Any info from anyone regarding this, or how they may be running the render client as a service would be greatly appreciated.

Hi @thestraycat, I'm sorry to disappoint you but the option to start the TeamRender Client via NSSM or SC or WinSW has not yet been restored.

I can only ask, to contact us via our official email address, to better describe the impact this issue is causing on your work to escalate the discussion.

Best, Riccardo

Have you tried running it without any plugins?

Hi thestraycat, thanks for reaching out us.

From the log reported, it seems like at least for TurbolanceFX you're using an outdated version against Cinema R21 and maybe something similar is happening with X-Particles.

Could you confirm you're able to "normally" run Cinema?
Can you better explain the purpose of using nssm.exe with Cinema 4D? Is it because you want the Cinema 4D render clients to start at OS startup?

Looking forward further comments, give best.

Thanks so much for the replies guys - I really appreciate it.

@mp5gosu
I've tried it without the plugins that the logs mention are problematic and the service still fails to stay up. (Strangely when running the Team Render Client.exe via the desktop it runs fine, still grumbles about the 2 plugins however both of those plugins are accessible and usuable.) When i remove the plugins and attempt to run the service i simply have less failure in the logs, but the service still suffers the same fate. The logs state:

Could not load dll. (relative:///opencl.dll) [win_dll.cpp(319)]
Cause: Windows System Error #193 [win_dll.cpp(315)]

@r_gigante
Hi there! I can run the render client.exe perfectly fine as a foreground application. However, i don't have a spare license to test running full-fat "Cinema" and there is no GPU in these render nodes so i'd expect some grumbling. Both the plugins that error in the logs do in fact run when i load up the render client as a foreground application regardless of the log entry. I've done tests using xparticles and Turbulence to test they are in fact working when team render client is started from the desktop.

SO regardless of whether i remove the plugins or keep them, then run the service, the service goes into a perpetual cycle of restarting always exiting at the same point and writing the same info out to a log file over and over. Below is the only line in the log that references an error.

Could not load dll. (relative:///opencl.dll) [win_dll.cpp(319)]
Cause: Windows System Error #193 [win_dll.cpp(315)]

Your right in regards to nssm.exe, I use it purely to run the render client as a service, as it's less disruptive during patch cycles, stops people logging the clients off via RDP, and there's also some logic within nssm.exe to help the render client restart if it senses errors etc. However for testing sake i've turned off that functionality. I am using the same nssm config and options as i had done previously for R19 which worked flawlessly.

Do you know what the reference too win_dll.cpp is in my error log?

Hi, I've tried to reproduce the issue here and I confirm that your behavior can be reproduced. R21, differently from R19 and r20, actually crashes and the reason of the crash has nothing to do with missing references to external libraries.

With R21 a new licensing mechanism has been released which could likely conflict with nssm preventing it to be used to manage the TR 21 client as a service.

I'll keep informed about further investigation outcomes.

Cheers, R

@rgigante - Amazing! Thanks for taking the time to recreate that! It does definitely seem to be a thing. Your results seem exactly the same as mine.

Are there any Team Render Client.exe run time flags that can be passed as arguments to nssm do you think ?

@r_gigante - Did you get any further with the issue at all? Is there anything i can do to help?

@r_gigante - I take it this one's got you stumped? Not straight forward i'm assuming!

Hi @thestraycat, we're still investigating the issue since using nssm is not officially supported on Windows 10.

As a temporary workaround, considering that the scope of having it installed as a service it to just have it started at the boot, you might consider to add the TeamRender Client executable among the programs being run at the startup: this can be done be creating an alias to the program - in your case the TR client - inside C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp or, if depending on a local credential, in C:\Users[local user]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.

Finally, although it doesn't change the overall results - I warmly invite the drop nssm and have a look to sc.exe which is a similar utility provided directly by Microsoft and delivers the same functionalities delivered by the first.

Cheers,

Cheers, R

@r_gigante said in Cinema 4D Client R21 Service Creation:

Hi @thestraycat, we're still investigating the issue since using nssm is not officially supported on Windows 10.

Hi r_gigante, thanks for looking into it, i know it's not simple. I had a look on the NSSM website and it does seem to be supported on windows 10 as per the website:

But i totally understand that nssm + c4d isn't.

As a temporary workaround, considering that the scope of having it installed as a service it to just have it started at the boot, you might consider to add the TeamRender Client executable among the programs being run at the startup: this can be done be creating an alias to the program - in your case the TR client - inside C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp or, if depending on a local credential, in C:\Users[local user]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.

Yeah, as a work around i likely will, but this dosn't real deal with auto starting the application during failure and isn't as resilient as running it as a service, we also run into issues with security banners and have monitoring systems tied into looking specifically for this service etc.

Finally, although it doesn't change the overall results - I warmly invite the drop nssm and have a look to sc.exe which is a similar utility provided directly by Microsoft and delivers the same functionalities delivered by the first.

Thanks for the suggestion, However sc.exe isn't as flexible as nssm (which is where nssm derived it's name and use case from NSSM -> (Non-Sucking-Service-Manager) and adds a comprehensive set of features to service creation.

Being able to use sc.exe would be my preference over running a scheduled task at startup. Do have any information or tips or a working service creation command to get R21 working under sc.exe?

Thanks for all your help on this.

@thestraycat said in Cinema 4D Client R21 Service Creation:

Being able to use sc.exe would be my preference over running a scheduled task at startup. Do have any information or tips or a working service creation command to get R21 working under sc.exe?

At the moment R21 is not capable to be run as a service both with NSSM and SC. For the time being I don't have any further update on the topic, but I'll get back to you as soon as we can identify the cause of this incompatibility.

Thanks, Riccardo

@r_gigante - Thanks for confirming. Well it seems something substantial has changed for this to suddenly stop working, which is a shame as it effects our farm hugely. I wouldn't want to move away from C4D but unless a fix emerges or the functionality returns it's a real deal breaker for the likes of people running 30+ nodes

@thestraycat thanks for following up.
I feel your frustration, but at the moment being a workaround already there - you can start the different clients either using Scheduled Tasks or simply using the Start-Up folder in the ProgramData as mentioned above - I don't see it as a deal-breaker.

Rest assured that I've already notified our developers about the issue and hopefully based on our development prioritization.

Best, Riccardo

Strict Security GPO's make this a lot harder to do in an enterprise environment. Easier if it's just a PC under your desk..

@r_gigante - I take it there has been no progress or milestone date to return running the functionality of teamrender client running as a service (as of R21) going forward?

If so, this is a shame.

Due to our infosec requirements of being a larger company. Our Microsoft GPO policies stop us from running a foreground application as a logged in user due to it being a rather large security risk! As mentioned previously, there were added benefits for us running this as a service, not only was it a supported method of running an application, it also gave as resilience of our render service due to auto-starting failed agents due to things like memory leaks or bad jobs etc.

It also had fundamentally broken our monitoring and analytics pages that we expose to our user base that track the service running state.
It has also stopped us piping our service logs into log aggregation solutions like logarr and splunk.

It seems strange that the functionality existed. And now has been removed. I understand this may be in effect due to substantial re-writes but it seems an oversight to not keep the functionality or plan to return it. In essence, your making the product harder to run for larger organisations. It seems a bit counter productive.

Can someone explain the rationale behind the decision to remove the functionality?

Hi @thestraycat, I see your frustration but although the topic is still under my radar I can't give an estimation on when it will be addressed. Unfortunately this looks like a regression that has nothing to do with API or plugin development and I can only increase the awareness on the issue.

Rest assured that I'll try to keep you posted upon the discussion.

Best, R

I appreciate your reply @r_gigante

Should i be speaking to a different team? Can you recommend a good contact or any insight into how i can get this in front of the relevant people?

Hi @thestraycat thanks for following up.

@thestraycat said in Cinema 4D Client R21 Service Creation:

It seems strange that the functionality existed. And now has been removed. I understand this may be in effect due to substantial re-writes but it seems an oversight to not keep the functionality or plan to return it. In essence, your making the product harder to run for larger organisations. It seems a bit counter productive.

I've just opened a bug-report to confirm the regression, although it must be told that this was not a functionality intentionally added but something that by chance was simply working in past versions.

There's no other "better" team to contact because considering the technical level of the topic, it's likely you're going to be forwarded again here.

Best, R

Hi @thestraycat, quick follow-up: today I've internally discussed the issue and it's likely it will take a while (at least 6 weeks) before development resources can be spent on fixing it.

I'll get back on the topic as soon as I've fresh news.

@r_gigante Thank you for checking in and updating! I'll keep a keen eye on the thread, if you need me to test anything just shout.