[BUG] walinuxagent does not read environment variable PATH

[stawo]

I updated the PATH variable on my VM, but the walinuxagent seems not to pick up the changes, and uses and odd value for it.
Steps followed:

• update system-wide PATH by modifying /etc/environment
• restart the VM

If I ssh into the machine and perform the following commands:

• sudo su (to impersonate the user root)
• echo $PATH
  the returned value is correct.

If I execute echo $PATH in Azure Portal through the 'Run command' panel of the VM, a different value is returned in the output (different even from the one before I made the change).
I also executed the commands whoami (to be sure I am using the same user root in both cases) and more /etc/environment (to check that the right value is still there).
I tried to re-install and restart the agent, but not difference in the outcome.

• Distro and Version: Ubuntu 16.04 (Data Science Machine)
• WALinuxAgent version. Output of waagent --version:
  WALinuxAgent-2.2.32.2 running on ubuntu 16.04
  Python: 3.5.2
  Goal state agent: 2.2.40

[vrdmr]

When tried on multiple Ubuntu 18.04 VMs.

# From the VM: 
# varad@vm-dev:~$ sudo su
# varad@vm-dev:~$/home/varad# echo $PATH
# /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

From RunCommand:

# Enable succeeded: 
# [stdout]
# /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
# 
# [stderr]
# 

[stawo]

Please note that I was using the "Azure Data Science Virtual Machine for Linux", which is an Ubuntu 16.04 LTS, not 18.04.
Maybe that could be the reason of the mismatch.

[vrdmr]

Yes. There is a descrepency. From the Azure DS VM:

root@DSImage:/data/home/varad# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

From RunCommand output:

Enable succeeded: 
[stdout]
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

[stderr]

When I go inside the box, I run the script that gets downloaded, and see the output:

root@DSImage:/var/lib/waagent/run-command/download/0# bash script.sh
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

But in the stdout of the run-command, it captures only a subsection of the output.

root@DSImage:/var/lib/waagent/run-command/download/0# cat stdout
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

[vrdmr]

Looking at the environment variables for Daemon and ExtHandler. The ExtHandler launches the extension script and passed its env. variables to the child process.

root  1392  /usr/bin/python3 -u /usr/sbin/waagent -daemon
root  1543  \_ python3 -u bin/WALinuxAgent-2.2.44-py2.7.egg -run-exthandlers

root@DSImage:/# cat /proc/1392/environ
LANG=en_US.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
root@DSImage:/# cat /proc/1543/environ
LANG=en_US.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

[vrdmr]

More info for context:

root@DSImage:/lib/systemd/system# systemd-run --unit=yolo --scope echo $PATH
Running scope as unit yolo.scope.
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

[vrdmr]

My hypothesis is that the later two path variables (/usr/games:/usr/local/games) were added after the service (/usr/bin/python3 -u /usr/sbin/waagent -daemon) started. And the service never got it (becuase of our configuration of the unit file - eg: Ubuntu does not have environment key in the service section.)

This is an issue, especially if the environment variables are not being picked up. I will test it with 18.04 VMs as well.

[stawo]

@vrdmr , thanks a lot for the hard work!
Hope 18.04 doesn't show this behavior and that the Data Science Machine will be updated to that version.

[MatisseHack]

This is still an issue with all Linux VMs I've tried (mostly different versions of Ubuntu). Environment variables set in /etc/environment are not available to scripts run through this agent. Even simulating a login shell with #!/bin/sh -l doesn't load variables from /etc/environment. The only way I've gotten it to work is by having the bulk of my logic in a separate script and executing it with su. That workaround is very cumbersome though.