I think the problem is more that it is configured globally and not
per-destination. The real user stuff should all be per-destination and
not globally configured - since it should be possible to have like a
dedicated cluster for Galaxy jobs that just run jobs normally and a
general purpose cluster that submits jobs as the real user for
I have created a WIP pull request to move the configuration of these
options in that direction:
I haven't tested any of the changes in the PR yet - I just wanted to
open something to ensure I'd come back and finish things this cycle.
It is something that I have wanted to do for a while now - see
. In general there are a bunch of Galaxy
options for jobs that can only be configured in galaxy.ini but that
you may wish to have different values for depending on the job
You are going to want a smaller hack that can be backported just to
run the local job runner when that option is configured huh?
On Mon, Jan 25, 2016 at 3:38 PM, Peter Cock <p.j.a.cock(a)googlemail.com> wrote:
On Mon, Jan 25, 2016 at 3:33 PM, John Chilton
> On Mon, Jan 25, 2016 at 3:26 PM, Peter Cock <p.j.a.cock(a)googlemail.com> wrote:
>> On Mon, Jan 25, 2016 at 11:33 AM, Peter Cock <p.j.a.cock(a)googlemail.com>
>>> Hello all,
>>> We're currently looking at changing our Galaxy setup to link user
>>> with Linux user accounts for better cluster integration (running jobs as the
>>> actual user on SGE). As part of this, we've tried setting up a fresh
>>> installation on a new VM which has thrown up some issues.
>> We eventually got Galaxy to talk to SGE and submit jobs successfully
>> as the individual user's Linux account, with external_chown_script.py
>> being called to handle ownership of the files.
>> However, we would like to have some jobs (like the upload tool)
>> configured to run on the Galaxy server itself - and the easiest way
>> to do that is via the local job runner.
>> We tried both the "upload1" and "Convert characters1" tools.
>> jobs would start and seem to run, but then fail with a file permission
>> error (I don't have a stack trace to hand). From watching the Galaxy
>> terminal output from run.sh we could see external_chown_script.py
>> being called.
>> As a test, when we disabled the external_chown_script setting in
>> config/galaxy.ini then the local jobs would work.
>> When using the local job runner, does Galaxy run the child process
>> as the Galaxy user (my guess - no chown needed), or as the job
>> owner's Linux account (calling chown would be needed)?
> Yes, only the drmaa and pulsar runners really support running jobs as
> a different user. The local job runner pretty explicitly will only
> ever run as the Galaxy user.
In that case is there a bug that external_chown_script.py gets
called unconditionally, when it should only happen for the drmaa
and pulsar runners?