Bug 118262
| Summary: | 'at' jobs ignore LD_LIBRARY_PATH | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Doug Bramel <bramel> |
| Component: | at | Assignee: | Jason Vas Dias <jvdias> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-08-17 20:42:55 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 129682 | ||
| Bug Blocks: | |||
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/* /var/spool/at/a0000e01159f0c:LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib; export LD_LIBRARY_PATH /var/spool/at/a0000e01159f0c:echo LD_LIBRARY_PATH=$LD_LIBRARY_PATH (wait for a minute) $ grep LD_LIBRARY_PATH /var/spool/mail/$LOGNAME | tail -1 LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib Hi Jason, 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 /lib:/usr/lib:/usr/X11R6/lib [test@alt-100-91 test]$ echo 'echo LD_LIBRARY_PATH=$LD_LIBRARY_PATH' | at now+1minute 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/* /var/spool/at/a0003c0115a35f:echo LD_LIBRARY_PATH=$LD_LIBRARY_PATH 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 | tail -1 LD_LIBRARY_PATH= 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. Doug This bug is blocked by glibc bug 129682 - no setuid/setgid program can obtain LD_LIBRARY_PATH from the environment of a non-owner invoking user. 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. |
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): at-3.1.8-49 How reproducible: Always 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 at> Ctrl-D 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. Additional info: 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.