<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Having a large number of researchers able to run arbitrary code on the same submit host has a marked tendency to result in an overloaded host.  There are various ways to regulate that ranging from "constant scolding" to "aggressive quotas/cgroups/etc", but all involve some degree of inconvenience for all concerned.   So the desire is to do the same things they are currently doing, but on a node they do not have to share.<br></blockquote><div><br></div><div>If you have enough resources this could be a node managed by slurm, and you can use allocations to make sure people play nice.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For example, user X has a framework that consumes data from various sources, crunches it in Slurm by executing s* commands, and spits out reports to a NAS share.   The framework itself is long-running and interactive, so they prefer to keep it out of Slurm; however it is also quite heavy, and thus a poor fit for a shared system.  This can be addressed in many ways, but the lowest-effort route (from user X's point of view) would be to simply run the existing framework somewhere else so they do not need to share.<br></blockquote><div><br></div><div>Why not a dedicated node on your cluster? </div><div><br></div><div>Open OnDemand works really great for this use case! Give it a try, there is a nice demo install which you can use for testing it (no install required on your side): <a href="https://openondemand.org/run-open-ondemand" target="_blank">https://openondemand.org/run-open-ondemand</a></div><div><br></div><div>If that does not work for you, Jared's (*) suggestion of wrapping slurm commands in ssh scripts or the likes sounds like your best bet.</div><div><br></div><div>(*): Hi Jared, long time... hope you're doing well.</div></div></div>