MacOS Yosemite: Does setting PATH variable in /Library/LaunchDaemon work?

Question

I launch a thing written in python from plists in /Library/LaunchDaemons in Yosemite and I want it to run some scripots. And it seems not to take PATH fro the plist file. For example if I have this in /Library/LaunchDaemons/com.foo.foo.plist

<plist version="1.0">
<dict>
    <key>KeepAlive</key>
    <true/>
    <key>Label</key>
    <string>cz.foo.foo</string>
    <key>ProgramArguments</key>
    <array>
        <string>/opt/foomac/foo.py</string>
    </array>
    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
    </dict>
    <key>WorkingDirectory</key>
    <string>/opt/foomac/</string>
    <key>UserName</key>
    <string>administrator</string>
    <key>RunAtLoad</key>
    <true/>
    <key>SessionCreate</key>
    <false/>
    <key>StandardOutPath</key>
    <string>/var/log/foo/stdout.log</string>
    <key>StandardErrorPath</key>
    <string>/var/log/foo/stderr.log</string>
</dict>
</plist>

and my /opt/foomac/foo.py is

#!/usr/bin/env python
import os
print os.environ

then I would expect it to show /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin in the /var/log/foo/stdout.log as PATH. However only /usr/bin:/bin:/usr/sbin:/sbin shows there.

I also have /usr/local/bin /usr/bin /bin /usr/sbin /sbin

in /etc/paths and also setenv PATH /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin in /etc/launchd.conf but it still does not work. launchctl getenv PATH shows nothing.

Answer 1

We found out that launchd in Yosemite added PATH into environment but did not remove previous one. The following code:

#include <stdio.h>
int main(int argc, char  * argv[], char * envp[]){
    char ** a = envp;
    while (*a != NULL){
        printf("%s\n", *a);
        a++;
    }
    return 0;
}

Outputed PATH twice:

PATH=/usr/bin:/bin:/usr/sbin:/sbin
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

Python apparently took the first one. A workaround is running a program from bash script since it seems that bash uses the last one.

Also: this is almost certainly a bug, environment should not contain two items with same name.