AWS Thinkbox Discussion Forums

Linux System User Documentation

There’s a mention of a system user… ‘deadlin’ (I assume this is deadline)

Is that user hardcoded somewhere or is it merely a suggestion? (I have my own system/render user.)

I’m assuming this is meant for running the deadlinelauncher?? There’s not alot of description on how to deploy this for a linux environment in terms of users,groups,permissions,etc. It’d be great for someone to write some more on that for the docs… even if it’s just use cases.

My confusion lies with the launcher… assuming the launcher is running as a service on all my nodes and workstations… as user… say… ‘render’…

If users running the monitor want to send reboot or other messages to the slave nodes does it not have to be the same user? I’m a bit confused as normal.

Rob

The launcher doesn’t need a deadline-user, deadline-users are pretty much just for the monitor–most of the submission scripts ask for a username but you could write in someone else.

If you run the launcher as a service (which is what we do) it just becomes a command and control listening process but it’s running as network-user called ‘renderadmin’ which has admin power over our rendernodes and grants the launcher process admin level privileges to the system for shutdown etc. The monitor app can restrict which deadline-users can send certain commands through a permission based system but that’s all handled at the monitor level not the launcher level.

I get that and I can set it up… my post was given that this is a “Beta” discussion, the whole process from install to end user should be under evaluation. There is very little documentation about running as a service and the included deadlinelauncherservice file doesn’t really cut it. Here’s my launcher script which I need to debug-- Right now if I call ‘service deadlinelauncher startslave’ and the slave fails which does happen… it results in a defunct process. Where should I put the ampersand to fix that… not being a constant init script programmer?

[code]#!/bin/bash -f

Start/Stop Deadline Launcher Service for Linux

chkconfig: 2345 99 10

Description: Starts Deadline Launcher Service

DEADLINE_PATH=/opt/Thinkbox/Deadline6/bin
DEADLINE_LAUNCHER=${DEADLINE_PATH}/deadlinelauncher
DEADLINE_PULSE=${DEADLINE_PATH}/deadlinepulse

DEADLINE_USER=
LOGFILE=/var/log/deadlinelauncher.log
PULSE_LOGFILE=/var/log/deadlinepulse.log
PIDFILE=/var/run/deadlinelauncher.pid
PULSE_PIDFILE=/var/run/deadlinepulse.pid

VERBOSITY=1

if test ${VERBOSITY} -gt 0 ; then
ECHO=echo
VERBOSE=-v
else
ECHO=:
VERBOSE=
fi

start() {
if test -x ${DEADLINE_LAUNCHER}; then
$ECHO “Starting Deadline Launcher…”
touch $LOGFILE
su - ${DEADLINE_USER} -c “$DEADLINE_LAUNCHER -nogui -noslave” >> “${LOGFILE}” 2>&1 < /dev/null &
echo $! > ${PIDFILE}
else
$ECHO “Could not find Deadline Launcher”
exit 2
fi
}

stop() {
pid=cat $PIDFILE
if [ -n “$pid” ]; then
kill -QUIT $pid
rm $PIDFILE
$ECHO “Deadline Launcher Service Stopped”
else
$ECHO “Deadline Launcher Service is not running”
exit 3
fi
}

startslave() {
if test -x ${DEADLINE_LAUNCHER}; then
$ECHO “Starting Deadline Launcher with Slave”
touch $LOGFILE
su - ${DEADLINE_USER} -c “$DEADLINE_LAUNCHER -nogui -slave” >> “${LOGFILE}” 2>&1 < /dev/null &
else
$ECHO “Could not find Deadline Launcher”
exit 2
fi
}

stopslaves() {
if test -x ${DEADLINE_LAUNCHER}; then
$ECHO “Stopping running Deadline Slaves…”
touch $LOGFILE
su - ${DEADLINE_USER} -c “$DEADLINE_LAUNCHER -nogui -shutdown” >> “${LOGFILE}” 2>&1 < /dev/null &
else
$ECHO “Could not find Deadline Launcher”
exit 2
fi
}

startpulse() {
if test -x ${DEADLINE_PULSE}; then
$ECHO “Starting Deadline Pulse…”
touch $PULSE_LOGFILE
su - ${DEADLINE_USER} -c “$DEADLINE_PULSE -nogui” >> “${PULSE_LOGFILE}” 2>&1 < /dev/null &
$ECHO $! > ${PULSE_PIDFILE}
else
$ECHO “Could not find Deadline Pulse”
exit 2
fi
}

stoppulse() {
pid=cat $PULSE_PIDFILE
if [ -n “$pid” ]; then
kill -QUIT $pid
rm $PULSE_PIDFILE
$ECHO “Deadline Pulse Service Stopped”
else
$ECHO “Deadline Pulse Service is not running”
exit 3
fi
}

case “$1” in
‘start’)
start
;;
‘stop’)
stop
;;
‘restart’)
stop
sleep 2
start
;;
‘startslave’)
startslave
;;
‘stopslave’)
stopslaves
;;
‘startpulse’)
startpulse
;;
‘stoppulse’)
stoppulse
;;
*)
echo “Usage: $0 (start|stop|restart|startslave|stopslave|startpulse|stoppulse)”
;;
esac

exit 0
[/code]

I don’t have an answer to your query - but I wanted to jump in and agree that we want to hear everything from soup to nuts about how to make things better

cb

Where are you seeing this mentioned? There isn’t a need to run the launcher as a specific user, so if we have some misleading documentation, we’ll want to address that.

Our goal for Deadline 6 is to take a lot of the configuration that was necessary for Deadline 5 out of the equation. For example, in Deadline 5, the user that the Deadline applications ran as could affect how they were able to write to the repository. These problems are gone in Deadline 6 because 99% of data that gets written and later overwritten is now stored in the database. The special case that will remain will be plugin configurations, since we wanted to keep the plugins out of the database. Since this is an admin operation, and since we will provide the appropriate error message when it fails to write the config files, we felt this was acceptable.

Other than the config files for plugins, any file written to the repository will be written once (logs, for example). This avoids permission issues because you’ll never have a Deadline app running as one user try to overwrite a file written by another Deadline app as a different user.

This should simply configuring the sharing settings of the repository folder. Yes, it still needs full read/write permissions, but you shouldn’t have to worry about which specific accounts are accessing the repository, as long as they can write their own files and read any files that are already there. Really, this shouldn’t be any different than a typical asset server.

Now there is the notion of a Deadline user account, but this account is strictly used for operations within Deadline, and primarily the Deadline Monitor. They’re also used to tie jobs to a user. There is a setting in the Repository Options to use the System user as the Deadline users (which is probably what you were referring to earlier), but this is strictly for how Deadline determines who the Deadline user is. If this option is disabled, anyone can create a Deadline user account, and switch to another Deadline user account.

If you enable this option, your Deadline user will match the system user account, and the only way to change users is to log out of the machine and log back in as someone else. This is handy for studios that want to lock down the ability for changing Deadline users.

Hopefully that clears up the user confusion. If there is anything I was unclear about, please let me know!

Now on to the launcher service. Our goal is to not require manual setup of the launcher daemon/service, which is why we expose the option in the client installer. The installer should handle all of this for you. I’ve never seen the script you’ve posted before, so I’m guessing Edwin wrote that for you for Deadline 5. For Deadline 6, it would be great if you could test out installing the service with the installer and letting us know of any problems you run into.

Note that the deadlinelauncherservice we install is meant to be used by the installer when you enable the option to install as a daemon, so you don’t need to do anything manual with it.

Cheers,

  • Ryan
Privacy | Site terms | Cookie preferences