Description of problem: Some configuration script don't rely on any PATH to be set when they are run. Version-Release number of selected component (if applicable): 9.3.3-2.fc21 How reproducible: always Steps to Reproduce: 1. run postgresl-setup with PATH unset 2. 3. Actual results: Initializing database ... failed, see /var/lib/pgsql/initdb.log usr/bin/postgresql-setup: line 88: runuser: command not found Expected results: postgresql-setup should have initialized the database. Additional info: This was encountered with an ansible playbook on f19.
Created attachment 876405 [details] This fix failure of the script when PATH is unset
Ping ? Any issue with the patch ?
Nicolas, thanks for your report and patch. Sorry for the delay. > Some configuration script don't rely on any PATH to be set when they are > run. You claim that when you do this change, the postgresql-setup script perfectly works with $PATH unset? That does not seem to be truth - other binaries residing "somewhere" in $PATH are also used.. The vast majority of shell scripts definitely rely on PATH, postgresql-setup is not an exception. What is wrong IMO is that the script checks for /sbin/runuser existence (that binary could calmly be put in some other directory).
I don't know for the whole scripts on any systems of course. This bug is only about a dedicated case when using ansible remotly, not from a running system. Taking another common example as the /etc/init.d/functions, and there cannot be more generic example. The runuser is used without a full path, but at the same time, the PATH is explicitly set at the beginning of the script. I really think the content of the PATH shouldn't be implicitly expected And when initscripts was commonly used it was common to set the PATH explicitly to avoid trivial error like such So there is indeed two options: - Either explicitly set a working PATH - Or use the full path of each command. I've only tested fixing runuser and it worked with initdb, but indeed, others command silently failed.
Created attachment 893257 [details] Set PATH if it is unset and don't expect /sbin/runuser exists. Nicolas, thanks for your comment. I don't think playing much with PATH in postgresql-setup makes sense (appending, removing, checking whether any part exists already) but setting the PATH variable only when the variable is empty should be safe and I believe it will help you. Dunno whether this is correct from the Ansible POV. Trivial patch is attached, any comment welcome. Anybody: Please stop me if you don't want this patch to be applied in Rawhide. Pavel
/etc/init.d/functions uses that: --------------- # Set up a default search path. PATH="/sbin:/usr/sbin:/bin:/usr/bin" export PATH --------------- So it doesn't worry of what was actually set or not. but use that for all subsequent processes. In the worst case, one could call /usr/bin/postgresl-setup with the wrong PATH such as PATH=/opt/fedora/tomcat8/bin/ (when using Software Collection). I don't know how it behave with scl anyway, just had that in mind.
(In reply to Nicolas Chauvet (kwizart) from comment #6) > /etc/init.d/functions uses that: > --------------- > # Set up a default search path. > PATH="/sbin:/usr/sbin:/bin:/usr/bin" > export PATH > --------------- > So it doesn't worry of what was actually set or not. but use that for all > subsequent processes. /etc/init.d/functions is a special "starting" point. I don't think this would be OK also for postgresql-setup. > In the worst case, one could call /usr/bin/postgresl-setup with the wrong > PATH such as PATH=/opt/fedora/tomcat8/bin/ (when using Software Collection). > I don't know how it behave with scl anyway, just had that in mind. In case of Software Collections, PATH is just "extended" with some additional pathnames (with higher priority). If the PATH variable was broken with SCL, it is most probably packager mistake and we are not able to fix such situation from the script -- it must be fixed in particular collection.
Fix is in Rawhide, thanks for this bugreport! http://pkgs.fedoraproject.org/cgit/postgresql.git/commit/?id=533a1efbb6