/usr/local/etc/rc.d/uwsgi does re-invoke itself when processing profiles and relies on $0 to determine its own location. This works ok on a running system where/usr/local/etc/rc.d/uwsgi is invoked directly, but does not work on system startup, when $0 equals /etc/rc. The output in this case is: .. Processing uwsgi profile: myprofile /usr/local/etc/rc.d/uwsgi: /etc/rc: Permission denied .. This happens because rc.subr's run_rc_script function sources rc scripts to execute them, see man 8 rc.subr on that function: .. 4. If the rc.conf(5) variable rc_fast_and_loose is empty, source file in a sub shell, otherwise source file into the current shell. .. Fix: As a workaround, apply the following patch which replaces $0 with the exact path to the uwsgi rc script. Refactoring the script so that re-invoking itself won't be required would be a better (but more elaborate) fix.--a3avIuLUyosUDnP629hyPHfdcOzeEKmizOYv51axTalHzSYD Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" --- /usr/local/etc/rc.d/uwsgi~ 2012-04-19 18:48:25.000000000 +0000 +++ /usr/local/etc/rc.d/uwsgi 2012-04-19 18:48:25.000000000 +0000 @@ -80,7 +80,7 @@ elif [ -n "$1" ]; then for profile in ${uwsgi_profiles}; do echo "Processing ${name} profile: ${profile}" - $0 $1 ${profile} + /usr/local/etc/rc.d/uwsgi $1 ${profile} done exit 0 fi How-To-Repeat: An easy way to test the problem without rebooting is to create a script that simulates the behavior of /etc/rc (and /etc/rc.subr): echo "(set start ; . /usr/local/etc/rc.d/uwsgi)" >/tmp/rcsimul cd /usr/ports/www/uwsgi make -DBATCH install clean echo 'uwsgi_enabled="YES"' >> /etc/rc.conf echo 'uwsgi_profiles="myprofile"' >> /etc/rc.conf echo 'uwsgi_myprofile_flags="doesntmatter"' >> /etc/rc.conf /bin/sh /tmp/rcsimul Expected output: Processing uwsgi profile: myprofile /usr/local/etc/rc.d/uwsgi: /tmp/rcsimul: Permission denied Alternatively reboot the machine and check /var/log/messages or dmesg.
Responsible Changed From-To: freebsd-ports-bugs->danger Over to maintainer (via the GNATS Auto Assign Tool)
State Changed From-To: open->analyzed Hi, I can confirm the bug. I have added a temporary fix for this issue based on your change in the latest update, but a proper fix is needed. I will close this after I figure how to do it properly. Thanks for the report!
Responsible Changed From-To: danger->demon Over to new maintainer.
State Changed From-To: analyzed->closed Script now works as intended.