Bug 118262 - 'at' jobs ignore LD_LIBRARY_PATH
'at' jobs ignore LD_LIBRARY_PATH
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: at (Show other bugs)
1
All Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On: 129682
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-14 13:15 EST by Doug Bramel
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-17 16:42:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Doug Bramel 2004-03-14 13:15:04 EST
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.
Comment 1 Jason Vas Dias 2004-08-04 16:30:18 EDT
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
Comment 2 Doug Bramel 2004-08-05 11:12:58 EDT
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 
Comment 3 Jason Vas Dias 2004-08-11 16:04:29 EDT
 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.
Comment 4 Jason Vas Dias 2004-08-17 16:42:55 EDT
 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.

Note You need to log in before you can comment on or make changes to this bug.