I’m getting an error with Deadline 10.1.1.3 that I didn’t with 10.0.28.2. It’s a clean install for what’s intended to be a worker on linux.
The install goes smoothly but after it’s completed the launcher exits (instead of normally running in the background).
root@ed321ba7a8f2:/# /tmp/DeadlineClient-10.1.1.3-linux-x64-installer.run --mode unattended --connectiontype Remote --noguimode True --daemonuser conductor --launcherdaemon true --proxyrootdir mydeadlinercs:4434 --proxycertificate /tmp/Deadline10RemoteClient.pfx --enabletls true --tlscertificates existing
The Deadline 10 Launcher Service is not currently running.
The Deadline 10 Launcher Service has been started.
root@ed321ba7a8f2:
I’ve tried:
root@ed321ba7a8f2: /etc/init.d/deadline10launcher status
The Deadline 10 Launcher Service exited prematurely.
And then I try manually launching:
root@ed321ba7a8f2:/# /opt/Thinkbox/Deadline10/bin/deadlinelauncher --slave
WARNING: Ignoring HOME environment because effective user is root.
Port 17000 is already in use
Another Launcher is already running
Unable to determine the local listening port for the running Launcher.
Shutting down
I’ve tried changing the port number for LauncherListeningPort and it doesn’t make a difference, same error (with the updated port number).
I’m running inside a clean docker container based on debian stretch, so there is nothing else running. 10.0.28.2 worked fine in this exact setup.
Here’s the from installing - I haven’t run any additional commands
root@febd17b8fe82:/# cat /var/log/Thinkbox/Deadline10/deadlinelauncher-febd17b8fe82-2019-12-13-0000.log
2019-12-13 15:59:54: BEGIN - febd17b8fe82\root
2019-12-13 15:59:54: Operating System: Linux
2019-12-13 15:59:54: CPU Architecture:
2019-12-13 15:59:54: CPUs: 2
2019-12-13 15:59:54: Video Card:
2019-12-13 15:59:54: Deadline Launcher 10.1 [v10.1.1.3 Release (a53d3f404)]
2019-12-13 15:59:54: Port 17000 is already in use
2019-12-13 15:59:54: Another Launcher is already running
2019-12-13 15:59:54: Unable to determine the local listening port for the running Launcher.
2019-12-13 15:59:54: Shutting down
It’s complaining about port 17000 already being in use, it does check external and loopback interfaces when that check gets made. Maybe there’s something about this Docker setup that’s interfering?
I’ve got zero experience working with Docker, but maybe that port needs to be released, or made available in the config?
It’s also worth checking to see what the OS thinks, lsof -i -P -n should get a list of all the ports and who or what has a handle on them. Give that a spin and let me know what you see.
Docker’s networking can be the problem if you’re using host mode networking. In that case, the network bridge device isn’t created and you’re essentially passing the ports through directly. The moment you start a second instance it will fail.
Can you provide the flags your sending in during docker run here?
That all said, the “Another Launcher is already running” error you’re seeing there is typically normal if and only if a Launcher is actually running. The problem in particular here seems to be “Unable to determine the local listening port” which is determined from “/var/lib/Thinkbox/Deadline10/launcher.ini”. Can you also check to see if that’s being created? Unless you’re mounting it read-only with “-v /folder:/folder:ro” it should work just fine.
A reminder that this exact setup works with 10.0.28.2 and I’ve tried setting different ports in deadline.ini (with the same reesult).
Running lsof -i -P -n returned nothing.
My docker command is very basic: docker run -it 697be3831727 bash . I have no other containers running at the same time.
/var/lib/Thinkbox/Deadline10/launcher.ini is created by the installer inside the container. It’s contents are in the initial post. I’m not copying/mounting it to the container.
Are you able to check the code of the launcher to see under what conditions Port 17000 is already in use will be printed?
I looked into what causes that Port 17000 is already in use line to get printed. If the launcher isn’t able to bind to the port, it’ll fail and print that.
Could you share the docker file you’re working with? We’re not able to duplicate your results on our end and we must be missing something.
Oh of course. 10.1.1 had some bugs with IPv6. Specifically .net core wouldn’t properly advertise that IPv6 was disabled and so Deadline would attempt to bind and then fail. I worked around it in my container by enabling Docker’s support for that:
I don’t think 10.1.2 has a fix for this yet, but it should be in 10.1.3 whenever that gets released (I’m unable to say when).
If I recall correctly, I used “fc00::/64” because I’m doing the dirty IPv6 NAT thing at home for the computers that live under my stairs. It’s the equivalent of 10.0.0.0/8, just with a much bigger block of addresses. Should work fine for you if you’re not actually routing those packets.
Does anyone know if there’s a way to solve this on MacOS? I’ve also checked netstat and nothing is using the port. So I’m a bit lost on what’s going on there.
I’ve run into this issue and as far as I can tell, there’s no way to enable or disable ipv6 on our interface. I mean, I haven’t explored it on command-line too in depth. MacOS does let me manually setup ipv6 via the network interface panel. The options are simply Configure “Automatically”, “Manually”, or “Link-Local only” I’ve tried all 3 options and it doesn’t appear to help anything. I was wondering if routing tables might help at all?
[Edit] I apologize for bumping something as old as this. I believe the consensus is to stop using MacOS. It doesn’t support higher functions we need apparently. Thanks for your time.