In Yosemite, Apple removed support for environment variables in launchd.conf, so you need to find another way to set global, system-wide environment variables. For example, if you want solidangle_LICENSE to be automatically set, you could use a launchd plist.

Here’s an example plist that uses launchctl to set the solidangle_LICENSE environment variable.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs$
 <plist version="1.0">
 <dict>
        <key>Label</key>
        <string>com.solidangle.setenv</string>
        <key>ProgramArguments</key>
        <array>
        <string>/bin/launchctl</string>
        <string>setenv</string>
        <string>solidangle_LICENSE</string>
        <string>5053@replace-me</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
        <key>ServiceIPC</key>
        <false/>
 </dict>
 </plist>

You’ll need to edit this plist and save it in /Library/LaunchDaemons. The file permissions and ownership should look like this:

-rw-r--r--@ 1 root wheel 661 Oct 22 13:52 com.solidangle.setenv.plist

Use sudo chmod to set the permissions, and sudo chown root:wheel to set the ownerships.
Then load the plist:
sudo launchctl load -w /Library/LaunchDaemons/com.solidangle.setenv.plist

And then restart your machine.

References:

• Setting environment variables via launchd.conf no longer works in OS X Yosemite
• How to set an environment variable in Mac OS X launchd plist

If suddenly some scenes render with a watermark, but others don’t, that probably means someone saved those scenes with Skip License Check enabled.

A quick way to check this is with the Arnold log.

If you set the verbosity level to at least Warnings + Info, you would see this:

00:00:00   787MB WARNING | [rlm] skip_license_check enabled

if Skip License Check is enabled.

If you’re using MtoA and rendering Maya scenes, one way to avoid this problem is to render with the -ai:slc off flag (slc = skip license check).

In the very unlikely case that Skip License Check isn’t the problem, the set the verbosity level to Debug and check the log again.

If a workstation or render node can’t get a license, you can use the Arnold log to find out what’s happening. If you set the log verbosity to debug, you can see where Arnold is trying to find a license server, whether or not Arnold can connect, and whether Arnold is being refused a license.

First, let’s look at what success looks like:

00:00:00   703MB         | [rlm] checking connection to license servers ...
00:00:00   703MB         | [rlm]  5053@StephenBlair-PC ... UP
00:00:00   703MB         | [rlm] checkout of "arnold 20140917" from StephenBlair-PC in 0:00.01
00:00:00   703MB         | [rlm] expiration date: 31-dec-2016 (768 days left)

These log entries tell me that solidangle_LICENSE (or RLM_LICENSE) is set to “5053@StephenBlair-PC” and that Arnold was able to get a license. I know that solidangle_LICENSE is set because the log entry says “license servers” (plural). If solidangle_LICENSE isn’t set, there’s just one license server to check: the default 5053@localhost.

For example, if you’re running on the same machine as the license server, you might see something like this:

00:00:00    11MB         | [rlm] checking connection to license server on 5053@localhost ...
00:00:00    13MB         | [rlm] checkout of "arnold 20141103" from localhost in 0:00.02
00:00:00    13MB         | [rlm] expiration date: 31-dec-2016 (761 days left)

So, if solidangle_LICENSE isn’t set, then on a workstation or render node you’d see this in the log:

00:00:00   784MB         | [rlm] checking connection to license server on 5053@localhost ...
00:00:05   784MB WARNING | [rlm] could not connect to license server on 5053@localhost

Note the Arnold checks just one license server: 5053@localhost. If solidangle_LICENSE is set, Arnold will check at least two license servers.

If solidangle_LICENSE is set, but Arnold cannot reach the specified server, you’d see this:

00:00:00   751MB         | [rlm] checking connection to license servers ...
00:00:05   751MB         | [rlm]  5053@null ... DOWN
00:00:10   751MB         | [rlm]  5053@localhost ... DOWN
00:00:10   751MB WARNING | [rlm] could not connect to any license server

If the RLM server is up and reachable, but the solidangle ISV server is down, then you’d see this:

00:00:00   745MB         | [rlm] checking connection to license servers ...
00:00:00   745MB         | [rlm]  5053@StephenBlair-PC ... UP
00:00:03   745MB WARNING | [rlm] error checking out license for arnold (version 20140917):
00:00:03   745MB WARNING | [rlm]  * Communications error with license server (-17)
00:00:03   745MB WARNING | [rlm]  * Connection refused at server (-111

The RLM server is the main RLM service that manages all the ISV servers. The ISV servers serve licenses for specific software packages, like solidangle, foundry, or exocortex.

If there are no licenses available:

00:00:00   745MB         | [rlm] checking connection to license servers ...
00:00:00   745MB         | [rlm]  5053@StephenBlair-PC ... UP
00:00:00   745MB WARNING | [rlm] error checking out license for arnold (version 20141103):
00:00:00   745MB WARNING | [rlm]  * All licenses in use (-22)

If the licenses don’t support the newer version of Arnold you’re trying to use:

00:00:00    11MB         | [rlm] checking connection to license server on 5053@localhost ...
00:00:00    13MB WARNING | [rlm] wrong license version for "arnold 20141103", found 1 license for "arnold 20140701"
00:00:00    13MB WARNING | [rlm] your maintenance expired on 2014/07/01, please contact licensing@solidangle.com

If the licenses are expired:

00:00:00   745MB         | [rlm] checking connection to license servers ...
00:00:00   745MB         | [rlm]  5053@StephenBlair-PC ... UP
00:00:00   745MB WARNING | [rlm] could not find any license for "arnold 20141103", the license may be expired

Arnold licenses are shared by host. That means all Arnold instances running on the same computer share the same license.

For example, you can have multiple copies of Houdini running on your computer, all doing render regions with HtoA, and you’ll be taking just a single Arnold license. Same thing with Softimage and Maya.

License sharing is defined by your license. The share=h in your license means that all processes (aka instances) running on the same host (aka computer) can share a single license.

Even when licenses are shared, you will still see multiple checkouts in your license usage. For example, here’s my license usage when I have an IPR going in Maya, and render regions in Softimage and Houdini:

The debug log would show something similar:

It might look like there are three licenses checked out, but it’s not. It’s just one license, checked out three times (aka shared three times).

If I check my license pool status, I can see that one license is in use:

And if you have reporting enabled, you can check the report and see that all three licenses have the same share handle (which means that the license is being shared):

If you’re still using ARNOLD_LICENSE_HOST and ARNOLD_LICENSE_PORT, now’s the time to stop. As of Arnold 4.2.4.0, these deprecated environment variables are no longer supported.

Instead, use solidangle_LICENSE.

For example, if you currently have these environment variable settings:

ARNOLD_LICENSE_HOST=lic_server
ARNOLD_LICENSE_PORT=5055

you can replace them with this:

solidangle_LICENSE 5055@lic_server

Note: solidangle_LICENSE was added in Arnold 4.0.4 (released back in 23-May-2012).

Also new with Arnold 4.2.4.0 is the ability to use a .lic file instead of an environment variable. Just create a .lic file that looks like this:

HOST lic_server 5055

and put the .lic file in the same folder as Arnold (ai.dll, libai.so, or libai.dylib).

If you want to put the .lic file somewhere else, then you need to set solidangle_LICENSE to point to the lic file.

This case shows that if your license expires overnight, it may not be obvious that that is the problem the next morning. For example, in this case, the customer reported that:

• The RLM license server was running.
• The solidangle ISV server was running.
• But clients were reporting watermarks and “No license for product (-1)” warnings in the Arnold log:

  00:00:02   815MB WARNING | [rlm] error checking out license for arnold (version 20150428):
  00:00:02   815MB WARNING | [rlm]  * No license for product (-1)
  

• There were no errors in the ISV debug log in RLM Web Admin, just the Reread request by automatic@midnight entries (the RLM license server automatically rereads license files at midnight every day).
  

Although there were no errors in the log, a check of the ISV solidangle status page showed something wrong: where’s the License Pool Status???

And a quick look at the log files in the RLM folder revealed the problem:

05/02 00:00 (solidangle) ==== Reread request by automatic@midnight ====
05/02 00:00 (solidangle) Using options file solidangle.opt
05/02 00:00 (solidangle) Setting TIMEOUT for arnold to 120 secs.
05/02 00:00 (solidangle) 
05/02 00:00 (solidangle) Re-reading license files, supporting products:
05/02 00:00 (solidangle) (No valid non-expired licenses found)05/07 00:00 (solidangle) 
05/02 00:00 (solidangle) License files:
05/02 00:00 (solidangle)     arnold_eval_0000coffee_20150428.lic

Note that the license file name arnold_eval_0000coffee_20150428.lic includes the expiry date: 20150428

And you can always check the actual license file to see the expiry date on the license:

In RLM, an ISV server is a license server for a specific product. For Arnold, the ISV server is solidangle.

So if you see No ISV servers to start in your log:

05/07 15:52 (rlm) RLM License Server Version 11.2BL2

        Copyright (C) 2006-2014, Reprise Software, Inc. All rights reserved.

05/07 15:52 (rlm) License server started on StephenBlair-PC
05/07 15:52 (rlm) Server architecture: x64_w2
05/07 15:52 (rlm) License files:
05/07 15:52 (rlm)     arnold_eval_90b11c647d93_20150428.lic
05/07 15:52 (rlm)
05/07 15:52 (rlm) Web server starting on port 5054
05/07 15:52 (rlm) Using TCP/IP port 5053
05/07 15:52 (rlm) ... adding UDP/IP port 5053
05/07 15:52 (rlm) (No ISV servers to start)

That means there won’t be a solidangle ISV server running, and there won’t be any Arnold licenses available:

Here’s a couple of licenses that result in No ISV servers to start.

• This license is missing a line break. The ISV line has to be on a separate line; otherwise RLM won’t recognize the ISV statement and won’t find the ISV server name.

  HOST localhost 0000coffee 5053 ISV solidangle port=66666
  LICENSE solidangle arnold 20161030 28-apr-2015 1 share=h
    min_timeout=120 start=28-apr-2015 issuer=Stephen customer=00340
    issued=28-apr-2015 _ck=fed6ff299c sig="60P0453GDCA9UJKPGJSGAGJK8YWFY
    7M2K3CE5F822H1BS2TYR29EKEUCWGY70B9P1FWCTHJCSV"
  

• This license is a node-locked license, so there is no ISV line, and you don’t need a license server to use the license.

  LICENSE solidangle arnold 20150430 30-apr-2015 uncounted
    hostid=90b11c647d93 start=03-mar-2015 issuer=Stephen customer=00340
    issued=3-mar-2015 replace _ck=f9d7d6ce9c sig="60PG4512N1FRJ14HSNHACV
    7X25R5KR42PNBWUKR22M09CHC72GE07WRSGKJQJKF54C30FPFKSCG0"
  

  How do I know it is a node-locked license? First, there’s no HOST or ISV lines, and second, it’s uncounted. Only node-locked licenses have the uncounted keyword.

The technical reason for a “No ISV servers to start” message is that that RLM could not read the ISV line from the license file.

So, for example, if you somehow save the license file as a binary file that looks like this:

then you’ll get No ISV servers to start, because obviously there’s no ISV line in that file.

Note: You’ll also see The hostname in the license file(s) may be incorrect, but that warning can always be safely ignored.

05/14 09:17 (rlm) 
05/14 09:17 (rlm) WARNING: No license file for this host (StephenBlair-PC)
05/14 09:17 (rlm)          The hostname in the license file(s)
05/14 09:17 (rlm)          may be incorrect
05/14 09:17 (rlm) 
05/14 09:17 (rlm) License files:
05/14 09:17 (rlm)     arnold_eval_90b11c647d93_20150514.lic
05/14 09:17 (rlm) 
05/14 09:17 (rlm) RLM License Server Version 11.2BL2

	Copyright (C) 2006-2014, Reprise Software, Inc. All rights reserved.

05/14 09:17 (rlm) License server started on StephenBlair-PC
05/14 09:17 (rlm) Server architecture: x64_w2
05/14 09:17 (rlm) License files:
05/14 09:17 (rlm)     arnold_eval_coffee0000_20150514.lic
05/14 09:17 (rlm) 
05/14 09:17 (rlm) Web server starting on port 5054
05/14 09:17 (rlm) Using TCP/IP port 5053
05/14 09:17 (rlm) ... adding UDP/IP port 5053
05/14 09:17 (rlm) (No ISV servers to start)

Reserving licenses is an RLM feature and is documented in the RLM User Guide (see “The ISV Options File” section).

You use the RESERVE keyword in the ISV options file (solidangle.opt) to reserve licenses for specific users, machine names, or IP addresses.

For example, this reserves 2 licenses for machines with the specified IP addresses:

INTERNET_GROUP renderfarm 192.168.221.1 192.168.223.1 
RESERVE 2 arnold group renderfarm 

This reserves five licenses for named users:

GROUP myusergroup steve stephen steven stevie stevo
RESERVE 5 arnold group myusergroup 

You can edit the ISV options in the RLM Web Admin page. You need to restart the ISV server after you change the options. Here’s a short video walkthrough (no audio).

These warnings mean that Arnold can connect to the RLM license server, but Arnold cannot connect to the solidangle ISV server:

00:00:12 14MB WARNING | [rlm] * Communications error with license server (­17)
00:00:12 14MB WARNING | [rlm] * Connection refused at server (­111)

Usually the problem is that the solidangle ISV server is not running.

You can check the status of the solidangle ISV server with RLM Web Admin. I like the get the RLM diagnostics (Diagnostics > Run Diagnostics) from RLM Web Admin and review that.

In rare cases, the problem is something else, such as:

• Some sort of network connection problem. For example, I recently had a case where we would get these warnings when we used the IP address of the license server in solidangle_LICENSE. But as soon as we switched to using the hostname, everything worked.
• Another RLM instance is running and listening to port 5053, and that instance doesn’t have a solidangle ISV running. I heard about this second-hand, from a customer; I didn’t see it with my own eyes and I don’t know how it’s possible. You can have multiple RLM instances running, but each instance has to have a different port otherwise you get ” “Port 5053 in use, waiting…” messages and the second RLM won’t start.

The Problem

To use Autodesk licenses for Arnold when you batch render with Maya, Arnold must be registered in the Product Information file (aka the PIT file).

Normally the MtoA installer does this for you. But if you’re running Maya and MtoA from a network install, then Arnold won’t be registered in the PIT file, and you’ll see this in the Arnold log:

00:00:00 381MB WARNING | rendering with watermarks because of failed authorization:
00:00:00 381MB | [rlm] error initializing license system:
00:00:00 381MB | [rlm] * Can't read license data (-102)
00:00:00 381MB | [clm] product key not found (44)

and you’d see something like this in the Adlm.log:

337296 2017/11/03 12:29:54 Reason=Fatal error
337296 2017/11/03 12:29:54 ComputerName=WORKSTATION
337296 2017/11/03 12:29:54 OS=6.1.7601.Service Pack 1
337296 2017/11/03 12:29:54 File=AdlmIntLicense.cpp,Line=594
337296 2017/11/03 12:29:54 VendorID=6 [ADLMPIT]
337296 2017/11/03 12:29:54 VendorError=12 [The root information in Product Information Table XML file is missing]
337296 2017/11/03 12:29:54 Reason=Fatal error
337296 2017/11/03 12:29:54 ComputerName=WORKSTATION
337296 2017/11/03 12:29:54 OS=6.1.7601.Service Pack 1
337296 2017/11/03 12:29:54 File=AdlmIntLicense.cpp,Line=595
337296 2017/11/03 12:29:54 AdlmIntError=25 [The product key was not found]

Solution

MtoA includes pit/pitreg for registering Arnold in the PIT file, so you just need to run pitreg on the local machine, like this:

C:\solidangle\mtoadeploy\2017\pit\pitreg.exe
Succesfully added Arnold information to PIT file

Don’t do this:

cd C:\solidangle\mtoadeploy\2017\pit\
pitreg.exe

because you’ll get this error:

Failed to add Arnold information to PIT file (Error 26)

It’s not rocket science, but here’s a little application of the scientific method to technical support.

Observation

The Autodesk licensing system loads AdlmIntRes.xml

I used dtruss on macOS and Process Monitor on Windows to see what files are accessed by the licensing system. (On Linux, I would use strace)

On Windows, the file %LOCALAPPDATA%\Autodesk\Logs\AdlmIntRes.xml is loaded.

On macOS: $TMPVAR/AdlmIntRes.xml:

56944/0x16208b8:  stat64("/var/folders/vb/1d7zhsx97q7_ddz43nccbyj00000gn/T//AdlmIntRes.xml\0", 0x7FFF55D22F00, 0x0) = 0 0
56944/0x16208b8:  stat64("/var/folders/vb/1d7zhsx97q7_ddz43nccbyj00000gn/T//AdlmIntRes.xml\0", 0x7FFF55D22F30, 0x0) = 0 0
56944/0x16208b8:  open_nocancel("/var/folders/vb/1d7zhsx97q7_ddz43nccbyj00000gn/T//AdlmIntRes.xml\0", 0x0, 0x1B6) = 37 0

On Linux: /var/tmp/AdlmIntRes.xml

Hypothesis

Autodesk licensing will fail if there’s a problem with AdlmIntRes.xml

Testing

• Delete AdlmIntRes.xml
  No problem. The file is recreated
• Delete the contents of AdlmIntRes.xml and save the file.
  License authorization fails with the error [clm] error initialzing CLM (9)

One of the strange thing about supporting Arnold at Autodesk is that you have to be a guru-level licensing expert on Autodesk licensing (not RLM, but Autodesk licensing).

In this case, Maya 2019 would silently fail at startup. Sometimes you’d see the splash screen, but then that would just disappear.

• There was nothing in the Adlm.log

• No MayaAdlm log was created

• The MayaCLM log had only this:

  ERROR: checkoutLicense: Failed to authorize license

• The clm log did have this:

  JsProductLicenseFact.loadSelectedProductInfoKey - Unable to get selected product key due to unknown problem.

TIP All these log files are in the Temp folder.

• On Windows, look in %LOCALAPPDATA%\Autodesk\Logs
• On OSX, look in $TMPDIR
• On Linux, look in /var/tmp

Process Monitor confirmed that the ProductInformation.pit file was missing:

ProductInformation.pit is an all-important file used by the licensing infrastructure. Every Autodesk product must be registered in that pit file.

If ProductInformation.pit is missing, or corrupted, then everything stops working.

Monthly, annual, and 3-year single-user subscriptions of Arnold 6 are now available on the Autodesk e-store

No more license servers! With a new single-user subscription, you just sign in with your Autodesk ID.

Just Sign In for C4DtoA

Just Sign In for MtoA

Arnold 7 is a new licensing version: Arnold 2022

(Arnold 6 was Arnold 2020, and Arnold 5 was Arnold 2018)

What does this mean for you?

• If you have network licenses, the contract manager has to go to manage.autodesk.com and generate a new network license.
• If you have single-user licenses, open the Arnold License Manager and check that Arnold 2022 is registered on your machine. Most, but not all, of the plugin installers will register Arnold.

When you click Register in the Arnold License Manager, it runs the Autodesk tool AdskLicensingInstHelper. All Autodesk products use this tool to register themselves with Autodesk licensing.

Check the License Manager log

If you get Failed to register Arnold product, check the Arnold License Manager log.

On macOS:

1. Open the Arnold License Manager.
2. In the menu bar, click Arnold License Manager > About Arnold License Manager.
3. In the About dialog box, click Show Log.
4. Click Copy to copy the log, and send it to Autodesk licensing support.

On Windows:

1. In the Arnold License Manager, click Help > About.
2. Click Copy to copy the log.

If you want to try and troubleshoot the problem yourself, find the line that runs the AdskLicensingInstHelper register command. It will look something like this:

2021-11-08 11:13:10 DEBUG | [clmv2] run: "/Library/Application Support/Autodesk/AdskLicensing/Current/helper/AdskLicensingInstHelper" register --prod_key C0PL1 --prod_ver 2020.0.0.F --config_file /Applications/Autodesk/Arnold/mtoa/2022/license/pit/ArnoldConfig.pit --lic_method USER --eula_locale en_US

Under that line, there will be some log messages describing why the command failed.

Reinstall the licensing

In some cases, a complete uninstall and then re-install of “single-user licensing” can fix the problem.

In a Terminal, run these commands:

   cd ~/Autodesk/LicensingInstaller
   sudo ./uninstall.sh

sudo will ask you to type your password. Press ENTER after you finish typing.

Then start the Arnold License Manager and switch to Single-user licensing. The license manager will ask if you want to install single-user licensing.

If you get this error, it means that Arnold is not registered in the Autodesk product information file.

With Arnold 5.3 and later, you use the AdskLicensingInstHelper tool (all Autodesk software now uses AdskLicensingInstHelper). The pitreg utility was removed in Arnold 5.3

Note AdskLicensingInstHelper requires that the Autodesk Licensing Service is installed and running on the machine.

For example:

sudo /opt/Autodesk/AdskLicensing/Current/helper/AdskLicensingInstHelper register --pk C0PL1 --pv 2020.0.0.F --lm NETWORK -cf /opt/Autodesk/arnold/maya2019-4.2.0/license/ArnoldConfig.pit

or

"C:\Program Files (x86)\Common Files\Autodesk Shared\AdskLicensing\Current\helper\AdskLicensingInstHelper.exe" register --pk C0PN1 --pv 2022.0.0.F --lm NETWORK --cf "C:\Program Files\Autodesk\Arnold\maya2022-5.0.0.2\license\ArnoldConfig.pit"

In addition to registering Arnold in the global ProductInformation.pit file used by all Autodesk products, AdskLicensingInstHelper also registers Arnold with the Autodesk licensing service (that’s for single-user licensing).

The ProductInformation.pit file is located here:

• /var/opt/Autodesk/Adlm/.config/ProductInformation.pit
• C:\ProgramData\Autodesk\Adlm\ProductInformation.pit
• /Library/Application Support/Autodesk/Adlm/.config/ProductInformation.pit

Here’s the help for the register command:

C:\Users\blairs>"C:\Program Files (x86)\Common Files\Autodesk Shared\AdskLicensing\Current\helper\AdskLicensingInstHelper.exe" -help register
NAME:
   AdskLicensingInstHelper - Manage products registration with Autodesk Licensing

USAGE:
   AdskLicensingInstHelper.exe [global options] command [command options] [arguments...]

VERSION:
   2.11.0.666

COMMANDS:
     register    Register product with the licensing components. Requires admin rights
     deregister  Deregister product from the licensing components. Requires admin rights
     list        List all products registered with licensing components
     change      Change registered product
     help, h     Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --verbose, -d  [O] Output verbose log
   --help, -h     show help
   --version, -v  print the version

Or, “things that happen when you use single-user licensing on a render node”

In this case, a Houdini command-line render with Arnold (HtoA) failed because the AdskLicensingAgent failed to start.

---------------------------
AdskLicensingAgent
---------------------------
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: minimal, offscreen, webgl, windows.

---------------------------
OK  
---------------------------

After AdskLicensingAgent crashed, the render would continue, but license authorization would fail:

00:00:00   148MB         | authorizing with license manager: user ...
00:00:31   153MB WARNING | rendering with watermarks because of failed authorization:
00:00:31   153MB         |  [clm.v2] timeout before callback was called

Using Process Monitor, I saw (as expected) that the problem was that the AdskLicensingAgent was loading Qt platform plugins from Houdini:

The solution? Set QT_QPA_PLATFORM_PLUGIN_PATH to point to the AdskLicensingAgent\platforms folder.

set QT_QPA_PLATFORM_PLUGIN_PATH=C:\Program Files (x86)\Common Files\Autodesk Shared\AdskLicensing\Current\AdskLicensingAgent\platforms

In this case, a macOS user was able to sign in using the Arnold License Manager in Cinema 4D R23, but not with the Arnold License Manager in Cinema 4D R25. Instead of opening accounts.autodesk.com in a browser window, all that happened was the “Signing in…” progress message:

The solution?
Install the latest Autodesk Identity Manager

The reason that Sign In worked in R23 was because that was with an older version of C4DtoA and Arnold. And that older Arnold did not use the Autodesk Identity Manager, it used Autodesk AdSSO (which Autodesk replaced with the Identity Manager).

Unfortunately, signing in with an older Arnold doesn’t help with a newer Arnold. You still need to sign in with the newer Arnold. But it works in the reverse direction: sign in with the latest Arnold, and that will work for the previous versions too!