SAS EG and envinmental variable (linux) at log in

[Andrea_Bocco]

I'm working on two different Linux servers (actually, they are more, but settings-wise they can be grouped in two groups) and having trouble moving sas code from one to the other one. Solved most configuration problems, I still can't execute OS code in, let's say, server A, from SAS EG (connected to SASApp).

Using a data step with pipe, I get as error that bash is unable to find the proper command (sas, sqlplus,...). I checked, from within SAS EG, user and PATH value on both servers just to be sure, and here's what I found. Server A presents a PATH which lacks every command aside from the base ones, while server B works fine with a PATH encompassing all commands needed. I looked into the bash_profile files of the corresponding users, and they were the same: server A user profile export the correct PATH and indeed directly calling additional command from the server works.

What am I missing? What SAS EG does when it logs in? Doesn't it launch the bash profile of the corresponding user?

[Kurt_Bremser]

No, the Object Spawner passes its environment to the Workspace Servers. Since the workspace servers are started without invoking a login shell, no profiles are read.

What you describe looks like an inconsistency between either the system environments (/etc/profile and /etc/environment) or the profiles of the user that runs the Object Spawner. That is most probably the SAS install user.

eg this is my PATH when I log on to the commandline:

/usr/local/bin:/sas/SASFoundation/9.4:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java6/jre/bin:/usr/java6/bin:/usr/local/bin:/usr/dt/bin:/home/myusername/bin

This is the path of the user sas when I log on as that:

/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/sas/bin:/usr/bin/X11:/sbin:/usr/dt/bin

and this is the log of a checking code from EG:

27         filename oscmd pipe "echo $PATH";
28         data _null_;
29         infile oscmd;
30         input;
31         put _infile_;
32         run;

NOTE: The infile OSCMD is:
      Pipe command="echo $PATH"

/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/sas/bin:/usr/bin/X11:/sbin:/usr/dt/bin
NOTE: 1 record was read from the infile OSCMD.
      The minimum record length was 77.
      The maximum record length was 77.

You can see it is the PATH of user sas, altough I'm logged in with my userid to the workspace server.

[Andrea_Bocco]

I'm a bit confused now.

First of all, along with the "echo $PATH" command, I passed to pipe "whoami" and the answers corresponded to what I expected (srv users). Moreover, I tried to log on SAS EG with different users and I still got the same result, so my educated guess is that the users that run the object spawners are the one whose profile I've looked at.

Second, there is no difference, at least for what concerns me, in environment setup between the two servers (at least this is what appears to my very limited knowledge of Linux). On the server B, the one working, the srv user .profile file doesn't set any environment variable which comes into play. All the setup for SAS is done in bash_profile. On the other server, the .profile file does nothing and a limited amount of setup, the one not showing up in PATH from SAS EG, is done in bash_profile.

Third, to confuse me even more, both PATH include the home of a different standard sas user (ins), and this is nowhere to be found even on server B. This suggest me I'm clearly not looking at the right configuration files.

[Kurt_Bremser · Accepted solution]

---

@Andrea_Bocco wrote:

I'm a bit confused now.

First of all, along with the "echo $PATH" command, I passed to pipe "whoami" and the answers corresponded to what I expected (srv users). Moreover, I tried to log on SAS EG with different users and I still got the same result, so my educated guess is that the users that run the object spawners are the one whose profile I've looked at.

This observation is perfectly correct. Although you operate as the effective user with which you logged in, you inherited the environment from the spawner, and therefore from the user that runs the spawner. Log on with that user, and you'll find the same PATH (and some other things).

---

Second, there is no difference, at least for what concerns me, in environment setup between the two servers (at least this is what appears to my very limited knowledge of Linux). On the server B, the one working, the srv user .profile file doesn't set any environment variable which comes into play. All the setup for SAS is done in bash_profile. On the other server, the .profile file does nothing and a limited amount of setup, the one not showing up in PATH from SAS EG, is done in bash_profile.

---

OK, so you should always look at bash_profile instead. .profile is used by sh and ksh (ksh being the default shell on AIX, which I'm working on).

I am not that familiar with the current Linux setup, but from my UNIX experience I expect some file in /etc that holds the default environment for a given server. With AIX, that's /etc/profile and /etc/environment.

---

Third, to confuse me even more, both PATH include the home of a different standard sas user (ins), and this is nowhere to be found even on server B. This suggest me I'm clearly not looking at the right configuration files.

---

After you've checked the default environment, determine which user is running the spawner. A

ps -ef|grep Spaw

should reveal that. Then log on as that user and check its environment.

[Andrea_Bocco]

Thank you for your help.

I checked all environment setup files in etc and, as I thought, there was nothing since it's a server shared among 5 groups and the policy is to define everything locally. I used the command you suggested and it revealed the ins users were the ones responsible for calling the object spawner as I supposed at the beginning looking at the PATH values. So I'm now 90% sure I have to edit those files, which is a thing I can't do by myself because of authorization issues and I will unfortunately know only in 3-4 weeks if it's right (still, I have to provide authorized people, who know nothing about what I'm doing, with locations and new versions of the files to be edited... smart policy).

There's still however one thing that bugs me. That missing 10% is due to the fact that the whoami command from SAS EG returned srv users instead of ins ones, under every login user I tried, even the same ins ones. Why?

[Kurt_Bremser]

If you use SAS token authentication, or a pooled workspace server, the SAS process will run with a generic user (default name for that is sassrv).

Which means that it's not necessary to maintain system userid's for every single SAS user. But it removes some of the control over user behaviour that the operating system can provide.