I’m interested in a setup that can run deadlinelauncher as a daemon if no user is logged in, and with a gui once a user starts a graphical session.
When a machine is not used by an artist and doesn’t have any active user sessions the deadlinelauncher should run with deadlinelauncher -daemon -nogui. Once a user logs into a user session the previous process needs to be stopped and deadlinelauncher needs to start to provide a GUI and work for idle detection.
What I’ve tried:
Run a service as root that launches deadlinelauncher -daemon -nogui on startup (This service is provided by Deadline by default with systemctl start deadline10launcher.
Then create a service deadline_user that launches deadlinelauncher and conflicts with the previous service and is wanted by: graphical-session.target. I can then enable that service globally with systemctl --global enable deadline_user. This successfully stops the daemon and starts the gui while the user is logged in.
However on log off the daemon is not restarted again and I don’t know if there’s a good way to start it.
Possible Solution
As a possible solution I found this post describing how to start a target which in return would start the daemon.
I am wondering, do I really need to do all of this extra work or am I missing something with the existing Deadline installation that would already allow me to do what I want?
Do I need to manually create these service scripts to handle this scenario?
Is there a better solution?
Services that are already running should get a SIGTERM, so yes it would be inefficient to try to start the daemon right before a shutdown/reboot. I was just trying to answer the part about having a script run on logout from a GUI session.
For clarity: Does the user who is logged on (graphical session) also need to run a worker (as their user)?
I was just trying to answer the part about having a script run on logout from a GUI session.
Yes, this makes sense. Good solution for that part, thank you!
For clarity: Does the user who is logged on (graphical session) also need to run a worker (as their user)?
Yes in my mind, the reason to end the deadline10launcher -daemon -nogui process and start a deadline10launcher process is so that idle detection works and so workers can easily be started and terminated when users are logged in. Maybe they forget to log out at night, or step away for lunch, which provides the perfect opportunity to start a worker.
Services that are already running should get a SIGTERM, so yes it would be inefficient to try to start the daemon right before a shutdown/reboot.
Maybe I can elaborate: I don’t know how to do something that fulfills both requirements:
Launch a process when no user is logged into a graphical session.
Don’t launch a process when a user is logging off as part of the shutdown sequence.
Maybe I’m overthinking this and the shutdown sequence will just shut down the process that just got launched. I will try this next.
I think it may be overkill to try to catch if the session was exited or finished/died. If you want to try this, you can just add in: ExecStartPre=/bin/sleep 30 to the unit file so it will sleep for 30 sec before re/starting the daemon. I hesitate suggesting this b/c I think it would be fine to leave it as is and let shutdown terminate and/or kill the processes.
I ended up using X11’s /etc/X11/xinit/xinitrc.d/*.sh and gdm’s /etc/gdm/PostSession/Default scripts to stop the daemon and start the gui and then stop the gui and start the daemon.
I wasn’t able to use gdms PreSessionscript as I couldn't connect to the user's desktop session from there. Unfortunatelyxinitrc.d` scripts run as the user so I had to launch my script as sudo to be able to launch deadlinelauncher as root.
Interesting… this is exactly what I’m trying to figure out atm as well (Centos)
We need a deadlinelauncher running to leverage Worker Scheduling (idle detection) but it seems like this feature is only useful when a user is logged into thier machine. they get popups etc…
We want to get the deadlinelauncher into the users taskbar, which means it has to be run from the users profile, ie autostart. But when the user logs out down comes the deadlinelauncher process, and any worker it has spawned, and therefore down will go any Worker Scheduling.
If we setup the deadlinelauncher as a system process (daemon) so its always running, we won’t get the deadlinelauncher into the users taskbar.
There are definitely two distinct cases here…
Have the worker and launcher guis in the users taskbar when the user logs in by way of autostart
(The user can manage their worker GUI at their own discretion, and worker scheduling can poke them when their machine is under utilized - ie spending hours surfing the deadline forum)
Stop the system deadlineworker -nogui deamon when the user logs in.
Start the system deadlineworker -nogui daemon when user logs out.
Perhaps one might use a system deadlinelauncher instead of a single deadlineworker process, but I’m not sure what the advantages of a launcher over a worker would be. We are just looking to have the users workstation run as a headless render farm node.
It also the case that when we run a worker from the users profile, the Workers Machine User will have the name of the user profile, and when its controlled by the system, the Workers Machine User will be root. I find that when there is a mix here, there is a mix of ownership in the render output which isn’t great.
What would be worse tho, is always having a worker running as a daemon on a user workstation. Jobs could get picked up on their machine while they are working and overrun their system resources without thier knowledge.