Deadline 5.1: Python.NET script mode not working on linux

Deadline
1

When I try to run a script in Python.Net mode, like the Scripts/TestShotgunConnection, I get the following error:

Could not run script because an error occurred
PyUnicodeUCS2_FromUnicode (System.EntryPointNotFoundExceptions)

I don’t know if this is related to my mono installation, which is mono 2.6.7, nor could I get a stacktrace on this.
My system is running ubuntu 10.04 LTS, for which I had to compile mono myself in order to get the right version.

As I would love to have standard python support for my own scripts, a hint on a solution would be much appreciated.

Thanks,
Sebastian

2

Hey Sebastian,

We’ll test it here and see if we can reproduce this. We’ll keep you posted.

Cheers,

  • Ryan
3

I tested on a fresh install of Ubuntu 10.04 and used badgerports to upgrade Mono to 2.10.5:
wiki.phonicuk.com/Installing-Mono-in-Ubuntu.ashx

I know we recommend Mono 2.6.7, as we’ve found that to be the most reliable (especially on OSX), but honestly I had no problems with my tests with 2.10.5 today. I tested Python.NET scripts, including the Shotgun tester, and I couldn’t reproduce the problem. That makes me wonder if it’s related to Mono, and the fact that it was built from source. It might be worthwhile to install 2.10.5 from badgerports to see if that helps.

Cheers,

  • Ryan
4

Hi Ryan,

Thanks for digging into this, and its good to hear that it works nicely with a stock ubuntu 10.04 LTS installation. The major difference would be that I use Xubuntu.

My first attempts used the badgerports mono installation, but it failed with the following error:

$: ./bin/Linux/deadlinemonitor.exe 

Unhandled Exception: System.TypeLoadException: Could not load type 'DeadlineMonitor.MainWindow' from assembly 'deadlinemonitor, Version=5.1.0.45970, Culture=neutral, PublicKeyToken=null'.
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type 'DeadlineMonitor.MainWindow' from assembly 'deadlinemonitor, Version=5.1.0.45970, Culture=neutral, PublicKeyToken=null'.

The mono version it would use is:

$: mono --version
Mono JIT compiler version 2.10.5 (Debian 2.10.5-1~dhx1~lucid1)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          supported, not enabled.
	GC:            Included Boehm (with typed GC and Parallel Mark)

It seems not to be able to find its own window, maybe the dll loading mechanism failed in some way. Its interesting that it works for me if I use version 2.6.7 directly, until the point where Python.Net is involved.

As you cannot reproduce it, it might just be easiest for me to setup a VM with a plain vanilla 10.04 LTS ubuntu installation.

Even though I so far have made plenty of bad experiences with mono, which makes me go ‘doh’ whenever I encounter software that uses it on non-windows platforms, it seems to help overall usability if you ship the software with your own mono version, which might even contain your very own patches.
Take http://www.plasticscm.com/ for instance, it comes with its own mono, and I had no problems whatsoever launching it on my machine. Its still crashy in gui mode, but I would attribute that to mono entirely.

I heared you are planning some major gui changes in an upcoming release, but I believe you will still have to rely on mono anyway. If that is the case, distributing your own mono with deadline might be a viable option to make life for non-windows people easier.

Cheers,
Sebastian

5

I just tried with the latest linux mint in a vm. It ships with mono 2.10.5.

The first time I tried to run deadline, I got this error:

./deadlinemonitor.exe 
The assembly mscorlib.dll was not found or could not be loaded.
It should have been installed in the `/usr/lib/mono/2.0/mscorlib.dll' directory.

Looking into it, I realized I had to install the mono cli 2.0 using apt-get install libmono-corlib2.0-cil

Now I am back to where I started, as deadline tells me the following:

./deadlinemonitor.exe 

Unhandled Exception: System.TypeLoadException: Could not load type 'FranticX.Collections.Specialized.StringCollection2' from assembly 'franticx, Version=2.0.0.45969, Culture=neutral, PublicKeyToken=null'.
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type 'FranticX.Collections.Specialized.StringCollection2' from assembly 'franticx, Version=2.0.0.45969, Culture=neutral, PublicKeyToken=null'.

Could it be that it didn’t load one of its own dlls for some reason ?

I am still wondering what the difference could be, as I am using the mono version that apparently worked for you when using the mono backport on ubuntu 10.04.
The good thing about this is that there seems to be a template for reproducing the issue, being

[]install latest mint 12 x64[/]
[] install mono corlib 2.0 [/]
[] try to run deadline [/]

Do you use the 32 bit or the 64 bit versions ? Maybe this is the difference we are looking for - my host OS is 64 bit as well.

Thanks,
Sebastian

6

Hi Sebastian,

Can you check if you have the mono-complete package installed? This ensures you have all the components you need. Some packages like mono’s WinForms and libdgiplus aren’t always installed by default, and Deadline relies on these for the UI.

We are looking at bundling Mono with the OSX version of Deadline. We can look at this for Linux as well, but OSX is our first priority since we find people have more issues with Mono on it.

Cheers,

  • Ryan
7

Hi Ryan,

With the mono-complete package, I am able to startup the monitor. On Xubuntu 10.04, where the badgerport is used, mono-complete causes a dependency issue, however it seems to be able to install enough packages for deadline to come up. On mint 12, mono-complete can be installed without issues, and the deadline monitor comes up.

On Xubuntu 10.04, I still see the issue explained in my first post in this thread.

On Mint 12, it said “libpython2.6.so not found” . Interestingly, on the deadline version I have from the studio, there is a python subdirectory in the deadline repository which seems to have python installations for all systems. In the clean, freshly downloaded version of deadline 5.1 that I use on mint, there is no such folder though. In the ./bin/Linux/ directory, there is a broken symlink to libpython2.6.so . If I point it to the respective file of the python distribution that our studio’s deadline repository contained, I still get the same error.
That got me thinking actually, as it would mean that this default symlink is not doing anything.
On Xubuntu, I also have a system native python 2.6 installation with a libpython2.6.so file in /usr/lib . Once I symlinked the python library deadline provides to /usr/lib, I was actually able to start the test_shotgunconnection script. In this case, this merely means I get past the error mentioned first, to a new one stating that the ‘time’ module could not be imported. This probably is because deadline doesn’t initialize the python libraries correctly.

To sum it up:
deadline’s python.net interpreter tries to use the system libraries instead of own bundled ones, which can cause all sorts of errors. In case of my xubuntu, it fails because my python 2.6 installation was compiled with a different unicode character size.
Also deadline seems to fail to properly initialize the python.net environment to make sure the standard libraries can be found, like time.

It would be great if you could find the time to reproduce these issues using mint 12 64 for instance, as it should run you through quite a lot of issues that probably most linux users have to go through as well. You might want to use the default deadline repository installation that can be downloaded from your site.

This feature is very important to me, hence I will do my best to help, just let me know if you need additional information.

Thank you very much,
Sebastian

8

Hi Sebastian,

If I recall, you guys were on the 5.1 beta right? That would explain why your current repository has a python folder. This was removed in later betas because it wasn’t necessary to have python installed with the repository. Around the time this changed, so did the way that Deadline’s python bundle was installed. That would explain the broken symlink in your Deadline bin folder. After this change was made during the beta, it was necessary to run the client installer again on each machine so that it could properly install the python bundle.

So it looks like your headaches are due to a bad Deadline installation. I would recommend upgrading your repository to the latest 5.1 release, and then run the client installer on your clients again to make sure python is installed properly:
thinkboxsoftware.com/deadline-downloads/

Cheers,

  • Ryan
9

Hi Ryan,

Thanks for the hint ! It makes me blush considering that all I really had to do was to actually install the client !

However, I believe that it might be worth putting in some safeties into the executables in future releases. Previously, in Deadline 5.0, it was perfectly fine to just install the DeadlineRepository as it contains all the executables you would ever need. Under that assumption, I tried to use deadline 5.1, and failed ungracefully.

The deadlinemonitor, and maybe other executables as well, now have to set some paths to make the python installation work. These paths are probably set under the assumption of a directory layout which in fact is available only in client installations. Therefore the deadline monitor, and maybe others, are not fully functional when started from the repository, as they cannot run python.net scripts for instance.

As they have been fully functional in previous releases, I would actually consider this an issue worth fixing, or at least put in some checks which make it fail with a message stating the issue. Otherwise I may doubt the usefulness of the executables being contained in the DeadlineRepository alltogether.
Of course, in the end I hope that based on my experience, a few lines of checking code may be added to make deadline behave more graceful in the mentioned cases, and make the time we spend on this issue a little bit less wasted :slight_smile:.

Cheers,
Sebastian

10

We can consider that if the python bundle changes. This was a unique situation where it changed during beta testing, and the final 5.1 release that went out to the public wouldn’t have had this problem. We tried to make it clear with the release notes for the betas when a reinstall of the client was required, and we also mention this in upgrade instructions for 5.1:
thinkboxsoftware.com/deadlin … Downgrades

But I’m sure we could do a better job of making this more clear.

The executables are in the Repository for auto-updating. If the client detects a newer version in the repository, they can automatically update themselves. This is so that rollouts of minor updates is as simple as just updating the repository and then restarting your slaves (of course, 5.1 was an exception to the rule due to the new python bundle). They aren’t meant to be run from directly within the repository, and we’ve tried to make it clear in the docs that all apps should be run from a client installation (even Pulse).

I guess we could try to give a more meaningful error message when it can’t be loaded (other than saying python.so could not be found). It’s tricky though to account for all possible ways that the client installation could be broken. For example, deadline.dll could be missing, which would cause all sorts of problems. :slight_smile:

Cheers,

  • Ryan
11

I agree to everything you commented on. Admittedly, I didn’t study the docs, instead I just went with what was working nicely so far.

Too true, but maybe you can check if the directories that you use internally in order to setup the bundled python installation actually exist. This way, you implicitly detect if you are launched from a repository (or any other possibly invalid directory structure) and provide a meaningful error message. The advantage of this might be that it would only be done if somebody actually tries using the python.net implementation.
Of course its a somewhat special case, so I would be hesitant too to put something like it into the code too, but maybe it would already be worth doing it if it just helps one or two other guys out there.

In any way, I thank you for the excellent help,
Sebastian