[SOLVED] weird $PATH in acpi scripts

[bilbotux]

Hi

I'm trying to map all my notebook acpi events to some useful stuff using /etc/acpi/actions/* scripts. For instance, I mapped the sleep button to a script lilke this:

Code: Select all

$ cat /etc/acpi/actions/btn_sleep.sh
#!/bin/sh

hibernate-ram --force

This was working great, but since a while (do not know what I've done since) it no longer works. After a long search, I manage to found that the PATH variable is wrong when acpid runs the script:

Code: Select all

$ cat /etc/acpi/actions/btn_sleep.sh
#!/bin/sh
echo $PATH > /tmp/acpiPath

$ cat /tmp/acpiPath
PATH=/bin:/sbin:/usr/bin��:/usr/sbin

Notice the werd two unknown chars at the end of the third path.

I have absolutely no idea about where to look to 'correctly' fix this (for know, I simply force the PATH to be /sbin:/bin:/usr/sbin:/usr/bin at the beginning of each of my scripts, but would like to understand it).

Some information about my computer that might be useful to help catch the problem: root is running zsh shell, and under root, echo $PATH gives /sbin:/bin:/usr/sbin:/usr/bin. I tried reverting root's shell to bash (without any .bashrc) , but it's the same. I think everything was working great about a month ago, as far as I remember.

if anyone has any idea about this, or if you need some more information, please let me know.

Thanks

[Katphish]

Hi,

Well, the #!/bin/sh at the top forces the use of /bin/sh which probably links to bash.

I would check /etc/profile for corruption along with ~/.bash_profile, ~/.bash_login, ~/.bashrc and ~/.profile if they exist.

[bilbotux]

Hi,

Well, the #!/bin/sh at the top forces the use of /bin/sh which probably links to bash.

I would check /etc/profile for corruption along with ~/.bash_profile, ~/.bash_login, ~/.bashrc and ~/.profile if they exist.

Having #!/bin/sh doesn't imply that sh (link to bash) will be used to run the script: infact, if I echo $SHELL in the script, it returns /bin/zsh (which is my root shell). But I've changed the root shell to bash, and checked that the script was really runned by bash and result of $PATH is still the same.
I've checked every file I could in /etc (using a grep on PATH as a base) and do not find any corruption at all. I'm really wondering where this can come from.

[desultory]

Having #!/bin/sh doesn't imply that sh (link to bash) will be used to run the script:

Exactly, when the script is invoked directly that line does not imply that behavior it specifies that /bin/sh must be used to execute the script.

infact, if I echo $SHELL in the script, it returns /bin/zsh (which is my root shell).

Which is the expected behavior, bash does not reset $SHELL if it is set in the invoking environment.

I've checked every file I could in /etc (using a grep on PATH as a base) and do not find any corruption at all. I'm really wondering where this can come from.

Given the contents of PATH in that environment, that value most probably originates as a corrupted version of a deliberately limited setting of PATH. Try verifying that the packages containing the programs which invoke these scripts are not corrupted. In general qcheck -v $package should be able to verify the files present match those which were installed, qcheck is part of app-portage/portage-utils. If the package is not corrupt, this behavior indicates the presence of a bug.

[bilbotux]

Given the contents of PATH in that environment, that value most probably originates as a corrupted version of a deliberately limited setting of PATH. Try verifying that the packages containing the programs which invoke these scripts are not corrupted. In general qcheck -v $package should be able to verify the files present match those which were installed, qcheck is part of app-portage/portage-utils. If the package is not corrupt, this behavior indicates the presence of a bug.

Well I do not know exactly which packages I should check, but I've checked everything related that comes to my mind (zsh, acpid, acpi, baselayout, udev, hal) and none of them seems corrupted (only binary files fails MD5-digest, probably because I use prelink; and there are also the /etc/conf.d files that I have modified, but they should not cause any problem at all). Do you think I have other packages to check ?

I'm not aware about how acpid executes script, so I don't know how it fills the environment variables to execute them.

[bilbotux]

Ok, I've found something:
when running acpid using /etc/init.d/acpid start, the PATH variable is corrupted. When shutting it down and lauching acpid manually (/usr/sbin/acpid) then the PATH is correct.
I will try to see why running it from init.d result in a corrupted path and will let you know if I come up with something.

Simply running:

start-stop-daemon --start --exec /usr/sbin/acpid

result in a bad PATH.

[bilbotux]

Ok, so this definitely have nothing to do with acpi; but with baselayout.

Code: Select all

bilbotux ~ # cat test.sh
#!/bin/sh
echo $PATH

bilbotux ~ # start-stop-daemon --start --exec ./test.sh
/sbin:/bin:/usr/sbin�:/usr/bin
 * start-stop-daemon: ./test.sh died

start-stop-daemon belongs to baselayout, and I'm using the experimental baselayout-2.0.0_rc6. However, this was working great a month ago, and on another computer using this same baselayout version I have no problem at all. But since /sbin/start-stop-daemon is a symlink to /sbin/rc which is a binary file, I do not know what to do next.

Ok, this is now fixed: problem was from baselayout (see bug http://bugs.gentoo.org/show_bug.cgi?id=199749).
Thanks