From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux)
Description of problem:
When running jobs via at or batch, the contents of the LD_LIBRARY_PATH environment variable are not passed on to the scheduled job.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set LD_LIBRARY_PATH to something
2. run at and tell it to report contents of $LD_LIBRARY_PATH:
prompt$ at now
at> echo $LD_LIBRARY_PATH > foo.txt
3. look at contents of foo.txt
Actual Results: foo.txt is blank, indicating that $LD_LIBRARY_PATH is not set.
Expected Results: foo.txt should have the contents of LD_LIBRARY_PATH as set in the shell from which at was called.
The at manpage says this about environment variables:
> The working directory, the environment (except for the variables TERM,
> DISPLAY and _) and the umask are retained from the time of invocation.
so I would expect that LD_LIBRARY_PATH would be passed on to the scheduled job. All other relevant environment variables seem to be passed on (e.g. substituting $PATH for $LD_LIBRARY_PATH gives the expected result). Unfortunately the lack of LD_LIBRARY_PATH makes scheduling programs dependent on user-defined libraries a pain.
I've tried this from tcsh and bash on Fedora and RH9 installs, always with the same result.
A simple workaround for bash exists, namely to prepend 'export LD_LIBRARY_PATH=<path>' to each job passed to at (for some reason, prepending a 'setenv' command under tcsh doesn't work). Another workaround is to have at call a script, and have the script set environment variables and launch the job. Nevertheless, this is something that at should be handling.
I can't reproduce this bug - it works everytime for me -
(at-3.1.8-56, FC2). Try these steps:
$ export LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib
$ echo 'echo LD_LIBRARY_PATH=$LD_LIBRARY_PATH' | at now+1minute
$ grep LD_LIBRARY_PATH /var/spool/at/*
(wait for a minute)
$ grep LD_LIBRARY_PATH /var/spool/mail/$LOGNAME | tail -1
I don't have a FC2 box to test it on, so perhaps it's been fixed since FC1.
I did try your procedure on my FC1 box (at-3.1.8-49), and it only works when
run as root, but never when run as a user. I set up a new user account and ran
your test, and I get the result I expected from my original post:
[test@alt-100-91 test]$ export LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib
[test@alt-100-91 test]$ echo $LD_LIBRARY_PATH
[test@alt-100-91 test]$ echo 'echo LD_LIBRARY_PATH=$LD_LIBRARY_PATH' | at
job 60 at 2004-08-05 10:55
At this point, running 'grep LD_LIBRARY_PATH /var/spool/at/* as root (since
/var/spool/at is not user-readable) gives not quite the expected result:
[root@alt-100-91 bramel]# grep LD_LIBRARY_PATH /var/spool/at/*
Note that there's no 'LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib'. If I run
the test as root (like I'm guessing you did), that line is there.
Returning to my test account for the remainder and waiting for the minute:
[test@alt-100-91 test]$ date
Thu Aug 5 10:55:01 EDT 2004
[test@alt-100-91 test]$ grep LD_LIBRARY_PATH /var/spool/mail/$LOGNAME |
Clearly the job went through, but $LD_LIBRARY_PATH was not transferred. Can
you verify that your test works in a non-root account for FC2? If it works for user
accounts in FC2 I'll be satisfied that it's been fixed.
This bug is blocked by glibc bug 129682 - no setuid/setgid program
can obtain LD_LIBRARY_PATH from the environment of a non-owner
at could be converted to not require setuid/setgid bits to be set -
will work on this for next at version.
It seems the glibc developers consider this not a bug,
but a security feature that is unlikely to be changed.
So you'll just have to set LD_LIBRARY_PATH manually
in your at jobs - it won't be recorded from your
invoking environment if you are not root.