Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 416959 - www-servers/uwsgi-1.2.3 init-script not working due to uWSGI shell parameter error
Summary: www-servers/uwsgi-1.2.3 init-script not working due to uWSGI shell parameter ...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Ultrabug
URL:
Whiteboard:
Keywords:
: 436202 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-05-21 18:08 UTC by bacce
Modified: 2012-10-31 15:12 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bacce 2012-05-21 18:08:48 UTC
Seems that uWSGI upstream has changed some of the shell-parameters with a late release, resulting in the init-script not starting the service as expected, cause it is still trying to invoke old shell parameters when starting the daemon.

In my special case, I noticed this to be true for the --file parameter, which seems to have changed to --file-serve-mode. I am not sure if other parameters in the init-script are affected as well.

This bug is reproducible by the following steps:
- emerge uwsgi-1.2.3
- ln -s /etc/init.d/uwsgi/etc/init.d/uwsgi.test
- cp /etc/conf.d/uwsgi  /etc/conf.d/uwsgi.test
- vi /etc/conf.d/uwsgi.test - set UWSGI_PROGRAM to any uwsgi application
- /etc/init.d/uwsgi.test start

Resulting error:
/usr/bin/uwsgi: option '--file' is ambiguous; possibilities: '--file-serve-mode' '--fileserve-mode'
getopt_long() error
 * start-stop-daemon: failed to start `/usr/bin/uwsgi'                                                                                                         [ !! ]
 * ERROR: uwsgi.test failed to start

Workaround:
sed -i 's/\-\-file/\-\-file\-serve\-mode/' /etc/init.d/uwsgi
Comment 1 Ultrabug gentoo-dev 2012-05-22 09:12:18 UTC
Thank you very much Brian, it's fixed in tree now.

+*uwsgi-1.2.3-r1 (22 May 2012)
+
+  22 May 2012; Ultrabug <ultrabug@gentoo.org> +uwsgi-1.2.3-r1.ebuild,
+  files/uwsgi.initd-r1:
+  Fix standalone init script thanks to Brian Wiborg, fix #416959.
+
Comment 2 keanu1031 2012-05-30 16:41:20 UTC
I hope it's alright to respond to this bug instead of opening another, since it seems they are very similar.

After upgrading from 1.0.2.1 to 1.2.3-r3, our uwsgi application failed to start.  We found that due to the new required use flags (any-of ( cgi erlang lua perl php python ruby )), certain parameters are hidden depending on whether --plugins is called:

$ uwsgi --help | wc -l
336
$ uwsgi --plugins python26 --help | wc -l
386
$ uwsgi --help --plugins python26 | wc -l #Order matters
336

However, it seems that --plugins isn't used at all in the init script.  Once I add "--plugins python26" (in my case) to the init script, it works fine with --file (or --wsgi-file, which was used in the previous init), but not --file-serve-mode.
Comment 3 Ultrabug gentoo-dev 2012-06-01 10:07:14 UTC
(In reply to comment #2)
> However, it seems that --plugins isn't used at all in the init script.  Once
> I add "--plugins python26" (in my case) to the init script, it works fine
> with --file (or --wsgi-file, which was used in the previous init), but not
> --file-serve-mode.

Hi mate, I take it you're using a standalone setup.

The conf.d file configuring the init script does not have a special variable for plugins so the order is for you to make. Since the --file/wsgi-file parameter looks to be available only after the python plugin call, I guess you'll have to do it that way in the UWSGI_EXTRA_OPTIONS= parameter.

If I'm missing something or your point, please open a new bug so we can discuss this further.

Cheers
Comment 4 Ultrabug gentoo-dev 2012-10-31 15:12:54 UTC
*** Bug 436202 has been marked as a duplicate of this bug. ***