Bug 167108 - www/uwsgi: rc script doesn't work on startup when profiles are used
Summary: www/uwsgi: rc script doesn't work on startup when profiles are used
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Dmitry Sivachenko
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-19 20:30 UTC by Michael Gmelin
Modified: 2019-01-04 14:37 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Gmelin 2012-04-19 20:30:10 UTC
/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.
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2012-04-19 20:30:21 UTC
Responsible Changed
From-To: freebsd-ports-bugs->danger

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 Daniel Gerzo freebsd_committer freebsd_triage 2012-05-01 22:31:06 UTC
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!
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2013-01-19 20:15:52 UTC
Responsible Changed
From-To: danger->demon

Over to new maintainer.
Comment 4 Dmitry Sivachenko freebsd_committer freebsd_triage 2013-01-24 14:30:16 UTC
State Changed
From-To: analyzed->closed

Script now works as intended.