Posts made by thestraycat

@r_gigante - Hi R.

Some time has past and i was wondering what progress you guys may have made on this issue?

@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.

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?

@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?

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 - 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

@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.

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

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

@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 ?

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?

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.