Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#905123: uwsgi don't start, can't open pid file
285 views
Skip to first unread message
Diego Roversi
Jul 31, 2018, 7:20:03 AM7/31/18
to
Package: uwsgi
Version: 2.0.17.1-2
Severity: normal
uwsgi don't start from init script. Also if I try to start manually:
/usr/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/searx.ini --daemonize /var/log/uwsgi/app/uwsgi.log
[uWSGI] getting INI configuration from /usr/share/uwsgi/conf/default.ini
[uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/searx.ini
In the log file I find this error:
Tue Jul 31 12:53:02 2018 - open("/run/uwsgi/%(deb-confnamespace)/%(deb-confname)/pid"): No such file or directory [core/utils.c line 3613]
Previous version (2.0.15) works fine with the same configuration.
Thanks in advance,
Diego.
-- System Information:
Debian Release: buster/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages uwsgi depends on:
ii uwsgi-core 2.0.17.1-2
uwsgi recommends no packages.
uwsgi suggests no packages.
-- Configuration Files:
/etc/default/uwsgi changed:
RUN_AT_STARTUP=yes
VERBOSE=yes
PRINT_CONFNAMES_IN_INITD_SCRIPT_OUTPUT=yes
INHERITED_CONFIG=/usr/share/uwsgi/conf/default.ini
/etc/init.d/uwsgi changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="app server(s)"
NAME="uwsgi"
DAEMON="/usr/bin/uwsgi"
SCRIPTNAME="/etc/init.d/${NAME}"
UWSGI_CONFDIR="/etc/uwsgi"
UWSGI_APPS_CONFDIR_SUFFIX="s-enabled"
UWSGI_APPS_CONFDIR_GLOB="${UWSGI_CONFDIR}/app${UWSGI_APPS_CONFDIR_SUFFIX}"
UWSGI_RUNDIR="/run/uwsgi"
UWSGI_DEFAULT_CONFNAMESPACE=app
[ -x "$DAEMON" ] || exit 0
. /lib/init/vars.sh
[ -r "/etc/default/${NAME}" ] && . "/etc/default/${NAME}"
. /lib/lsb/init-functions
. /usr/share/uwsgi/init/snippets
. /usr/share/uwsgi/init/do_command
VERBOSE=yes
WHAT=$1
shift
case "$WHAT" in
start)
set -x
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_command "$WHAT" "$@"
RETVAL="$?"
[ "$VERBOSE" != no ] && log_end_msg "$RETVAL"
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_command "$WHAT" "$@"
RETVAL="$?"
[ "$VERBOSE" != no ] && log_end_msg "$RETVAL"
;;
status)
if [ -z "$1" ]; then
[ "$VERBOSE" != no ] && log_failure_msg "which one?"
else
PIDFILE="$(
find_specific_pidfile "$(relative_path_to_conffile_with_spec "$1")"
)"
status_of_proc -p "$PIDFILE" "$DAEMON" "$NAME" \
&& exit 0 \
|| exit $?
fi
;;
reload)
[ "$VERBOSE" != no ] && log_daemon_msg "Reloading $DESC" "$NAME"
do_command "$WHAT" "$@"
RETVAL="$?"
[ "$VERBOSE" != no ] && log_end_msg "$RETVAL"
;;
force-reload)
[ "$VERBOSE" != no ] && log_daemon_msg "Forced reloading $DESC" "$NAME"
do_command "$WHAT" "$@"
RETVAL="$?"
[ "$VERBOSE" != no ] && log_end_msg "$RETVAL"
;;
restart)
[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$NAME"
CURRENT_VERBOSE=$VERBOSE
VERBOSE=no
do_command stop "$@"
VERBOSE=$CURRENT_VERBOSE
case "$?" in
0)
do_command start "$@"
RETVAL="$?"
[ "$VERBOSE" != no ] && log_end_msg "$RETVAL"
;;
*)
# Failed to stop
[ "$VERBOSE" != no ] && log_end_msg 1
;;
esac
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status|restart|reload|force-reload}" >&2
exit 3
;;
esac
-- no debconf information
Version: 2.0.17.1-2
Severity: normal
uwsgi don't start from init script. Also if I try to start manually:
/usr/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/searx.ini --daemonize /var/log/uwsgi/app/uwsgi.log
[uWSGI] getting INI configuration from /usr/share/uwsgi/conf/default.ini
[uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/searx.ini
In the log file I find this error:
Tue Jul 31 12:53:02 2018 - open("/run/uwsgi/%(deb-confnamespace)/%(deb-confname)/pid"): No such file or directory [core/utils.c line 3613]
Previous version (2.0.15) works fine with the same configuration.
Thanks in advance,
Diego.
-- System Information:
Debian Release: buster/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages uwsgi depends on:
ii uwsgi-core 2.0.17.1-2
uwsgi recommends no packages.
uwsgi suggests no packages.
-- Configuration Files:
/etc/default/uwsgi changed:
RUN_AT_STARTUP=yes
VERBOSE=yes
PRINT_CONFNAMES_IN_INITD_SCRIPT_OUTPUT=yes
INHERITED_CONFIG=/usr/share/uwsgi/conf/default.ini
/etc/init.d/uwsgi changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="app server(s)"
NAME="uwsgi"
DAEMON="/usr/bin/uwsgi"
SCRIPTNAME="/etc/init.d/${NAME}"
UWSGI_CONFDIR="/etc/uwsgi"
UWSGI_APPS_CONFDIR_SUFFIX="s-enabled"
UWSGI_APPS_CONFDIR_GLOB="${UWSGI_CONFDIR}/app${UWSGI_APPS_CONFDIR_SUFFIX}"
UWSGI_RUNDIR="/run/uwsgi"
UWSGI_DEFAULT_CONFNAMESPACE=app
[ -x "$DAEMON" ] || exit 0
. /lib/init/vars.sh
[ -r "/etc/default/${NAME}" ] && . "/etc/default/${NAME}"
. /lib/lsb/init-functions
. /usr/share/uwsgi/init/snippets
. /usr/share/uwsgi/init/do_command
VERBOSE=yes
WHAT=$1
shift
case "$WHAT" in
start)
set -x
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_command "$WHAT" "$@"
RETVAL="$?"
[ "$VERBOSE" != no ] && log_end_msg "$RETVAL"
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_command "$WHAT" "$@"
RETVAL="$?"
[ "$VERBOSE" != no ] && log_end_msg "$RETVAL"
;;
status)
if [ -z "$1" ]; then
[ "$VERBOSE" != no ] && log_failure_msg "which one?"
else
PIDFILE="$(
find_specific_pidfile "$(relative_path_to_conffile_with_spec "$1")"
)"
status_of_proc -p "$PIDFILE" "$DAEMON" "$NAME" \
&& exit 0 \
|| exit $?
fi
;;
reload)
[ "$VERBOSE" != no ] && log_daemon_msg "Reloading $DESC" "$NAME"
do_command "$WHAT" "$@"
RETVAL="$?"
[ "$VERBOSE" != no ] && log_end_msg "$RETVAL"
;;
force-reload)
[ "$VERBOSE" != no ] && log_daemon_msg "Forced reloading $DESC" "$NAME"
do_command "$WHAT" "$@"
RETVAL="$?"
[ "$VERBOSE" != no ] && log_end_msg "$RETVAL"
;;
restart)
[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$NAME"
CURRENT_VERBOSE=$VERBOSE
VERBOSE=no
do_command stop "$@"
VERBOSE=$CURRENT_VERBOSE
case "$?" in
0)
do_command start "$@"
RETVAL="$?"
[ "$VERBOSE" != no ] && log_end_msg "$RETVAL"
;;
*)
# Failed to stop
[ "$VERBOSE" != no ] && log_end_msg 1
;;
esac
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status|restart|reload|force-reload}" >&2
exit 3
;;
esac
-- no debconf information
Diego Roversi
Sep 10, 2018, 6:10:02 PM9/10/18
to
Hello,
I found out that problem is related to a patch to do_command file:
https://salsa.debian.org/uwsgi-team/uwsgi/commit/d35c0aaa538049d099bf41b6282656f1370d8574
I've reverted the double quotes in the file do_command , and now it starts fine.
Can you consider to revert those last changes? At the moment upgrading the package result in a not working program (at least without some workaround requiring to change default.ini file, that is overwritten in a following upgrade).
Thanks,
Diego.
--
Diego Roversi <die...@tiscali.it>
I found out that problem is related to a patch to do_command file:
https://salsa.debian.org/uwsgi-team/uwsgi/commit/d35c0aaa538049d099bf41b6282656f1370d8574
I've reverted the double quotes in the file do_command , and now it starts fine.
Can you consider to revert those last changes? At the moment upgrading the package result in a not working program (at least without some workaround requiring to change default.ini file, that is overwritten in a following upgrade).
Thanks,
Diego.
--
Diego Roversi <die...@tiscali.it>
Diego Roversi
Sep 17, 2018, 11:50:03 AM9/17/18
to
Dear maintener,
instead to revert changes to do_command, you can also just apply this simple patch:
--- do_command.orig 2018-07-10 10:41:47.000000000 +0000
+++ do_command 2018-09-17 15:28:57.799075703 +0000
@@ -80,7 +80,7 @@
ERRORS="$((ERRORS+$?))"
done 4< <(find "$UWSGI_APPS_CONFDIRS" \
-regextype posix-basic \
- -iregex ".*\\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype f \
+ -iregex ".*\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype f \
-print0 \
| sed -e "s:\\(^\\|\\x0\\)${UWSGI_CONFDIR}/:\\1:g" \
-e "s:\\([^\\x0/]\\+\\)\\([^\\x0]\\+\\)\\?/\\([^/\\x0]\\+\\)\\.${UWSGI_CONFFILE_TYPES_REGEXP}\\x0:\\1/\\3\\x0:g" \
It should be enough. It worked for me: I tested on a fresh vm with testing and sysvinit.
instead to revert changes to do_command, you can also just apply this simple patch:
--- do_command.orig 2018-07-10 10:41:47.000000000 +0000
+++ do_command 2018-09-17 15:28:57.799075703 +0000
@@ -80,7 +80,7 @@
ERRORS="$((ERRORS+$?))"
done 4< <(find "$UWSGI_APPS_CONFDIRS" \
-regextype posix-basic \
- -iregex ".*\\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype f \
+ -iregex ".*\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype f \
-print0 \
| sed -e "s:\\(^\\|\\x0\\)${UWSGI_CONFDIR}/:\\1:g" \
-e "s:\\([^\\x0/]\\+\\)\\([^\\x0]\\+\\)\\?/\\([^/\\x0]\\+\\)\\.${UWSGI_CONFFILE_TYPES_REGEXP}\\x0:\\1/\\3\\x0:g" \
It should be enough. It worked for me: I tested on a fresh vm with testing and sysvinit.
Jonas Smedegaard
Sep 17, 2018, 5:30:03 PM9/17/18
to
Quoting Diego Roversi (2018-09-17 17:45:22)
Thanks a lot. Above looks actually sensible (unlike reverting the whole
patch, which I looked into but then backed off from.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
patch, which I looked into but then backed off from.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
Jonas Smedegaard
Sep 17, 2018, 5:40:02 PM9/17/18
to
Quoting Jonas Smedegaard (2018-09-17 19:26:34)
Please describe exactly what failed before above change which succeeds
with that change applied. I.e. which uwsgi file paths were ignored
before which now gets included?
> Quoting Diego Roversi (2018-09-17 17:45:22)
> > Dear maintener,
> >
> > instead to revert changes to do_command, you can also just apply this simple patch:
> >
> > --- do_command.orig 2018-07-10 10:41:47.000000000 +0000
> > +++ do_command 2018-09-17 15:28:57.799075703 +0000
> > @@ -80,7 +80,7 @@
> > ERRORS="$((ERRORS+$?))"
> > done 4< <(find "$UWSGI_APPS_CONFDIRS" \
> > -regextype posix-basic \
> > - -iregex ".*\\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype f \
> > + -iregex ".*\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype f \
> > -print0 \
> > | sed -e "s:\\(^\\|\\x0\\)${UWSGI_CONFDIR}/:\\1:g" \
> > -e "s:\\([^\\x0/]\\+\\)\\([^\\x0]\\+\\)\\?/\\([^/\\x0]\\+\\)\\.${UWSGI_CONFFILE_TYPES_REGEXP}\\x0:\\1/\\3\\x0:g" \
> >
> > It should be enough. It worked for me: I tested on a fresh vm with testing and sysvinit.
>
> Thanks a lot. Above looks actually sensible (unlike reverting the whole
> patch, which I looked into but then backed off from.
No wait, sorrym, not even that makes sense to me.
> > Dear maintener,
> >
> > instead to revert changes to do_command, you can also just apply this simple patch:
> >
> > --- do_command.orig 2018-07-10 10:41:47.000000000 +0000
> > +++ do_command 2018-09-17 15:28:57.799075703 +0000
> > @@ -80,7 +80,7 @@
> > ERRORS="$((ERRORS+$?))"
> > done 4< <(find "$UWSGI_APPS_CONFDIRS" \
> > -regextype posix-basic \
> > - -iregex ".*\\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype f \
> > + -iregex ".*\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype f \
> > -print0 \
> > | sed -e "s:\\(^\\|\\x0\\)${UWSGI_CONFDIR}/:\\1:g" \
> > -e "s:\\([^\\x0/]\\+\\)\\([^\\x0]\\+\\)\\?/\\([^/\\x0]\\+\\)\\.${UWSGI_CONFFILE_TYPES_REGEXP}\\x0:\\1/\\3\\x0:g" \
> >
> > It should be enough. It worked for me: I tested on a fresh vm with testing and sysvinit.
>
> Thanks a lot. Above looks actually sensible (unlike reverting the whole
> patch, which I looked into but then backed off from.
Please describe exactly what failed before above change which succeeds
with that change applied. I.e. which uwsgi file paths were ignored
before which now gets included?
Diego Roversi
Sep 19, 2018, 4:00:03 PM9/19/18
to
On Mon, 17 Sep 2018 19:34:00 +0200
Jonas Smedegaard <jo...@jones.dk> wrote:
> No wait, sorrym, not even that makes sense to me.
>
> Please describe exactly what failed before above change which succeeds
> with that change applied. I.e. which uwsgi file paths were ignored
> before which now gets included?
>
Yes, you are right. In the end after some more test, I found out that the problem is that if you create a new vm, install uwsgi, configure and such, the first time you try to start it silently fail:
Jonas Smedegaard <jo...@jones.dk> wrote:
> No wait, sorrym, not even that makes sense to me.
>
> Please describe exactly what failed before above change which succeeds
> with that change applied. I.e. which uwsgi file paths were ignored
> before which now gets included?
>
root@sobenio:~# systemctl start uwsgi
root@sobenio:~# systemctl status uwsgi
● uwsgi.service - LSB: Start/stop uWSGI server instance(s)
Loaded: loaded (/etc/init.d/uwsgi; generated)
Active: active (exited) since Wed 2018-09-19 19:27:15 UTC; 4min 7s ago
Docs: man:systemd-sysv-generator(8)
Tasks: 0 (limit: 4915)
Memory: 0B
CGroup: /system.slice/uwsgi.service
root@sobenio:~# systemctl stop uwsgi
root@sobenio:~# systemctl start uwsgi
root@sobenio:~# systemctl status uwsgi
● uwsgi.service - LSB: Start/stop uWSGI server instance(s)
Loaded: loaded (/etc/init.d/uwsgi; generated)
Active: active (running) since Wed 2018-09-19 19:31:30 UTC; 2s ago
Docs: man:systemd-sysv-generator(8)
Process: 10058 ExecStop=/etc/init.d/uwsgi stop (code=exited, status=0/SUCCESS)
Process: 10098 ExecStart=/etc/init.d/uwsgi start (code=exited, status=0/SUCCESS)
Tasks: 7 (limit: 4915)
Memory: 76.9M
CGroup: /system.slice/uwsgi.service
├─10206 /usr/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/searx.ini --daemoni
├─10212 /usr/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/searx.ini --daemoni
└─10213 /usr/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/searx.ini --daemoni
Sorry for the noise. The initial problem (can't open pid file) was caused by not having set the UWSGI_DEB_* variables, when I launched manually uwsgi.
The more frustrating things is the difficult to debug this kind of problem (I also hit the bug #900174 during test, and having no autoload=true in default.ini would help), where uwsgi don't start but no significant output is given. I suggest to document the way to manually launch, that is very useful to troubleshooting. You can find in bug #900174, but I repost here:
# UWSGI_DEB_CONFNAME=hello UWSGI_DEB_CONFNAMESPACE=app uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/hello.ini
Jonas Smedegaard
Sep 23, 2018, 5:30:04 AM9/23/18
to
Control: retitle -1 uwsgi: Please better document UWSGI_DEB_* vars
Control: severity -1 minor
Control: tag -1 wontfix
Hi Diego,
Quoting Diego Roversi (2018-09-19 21:46:26)
I am sorry your debugging was distracted by bug#900174 - I have now
better understood that one and _that_ bug should be fixed now with
2.0.17.1-4 released a moment ago.
I disagree that bypassing init scripts and using some parts of them in
custom ways should be better documented: It _is_ already documented
inside those scripts you tried to use, and the way you use them is very
much _unsupported_ ways of using them.
I therefore flag this as wontfix.
Nevertheless I apprecicate your helping out here: It was instrumental in
pushing forward a fix for bug#900174! Hope you will continue to report
bugs against uwsgi - there are no doubt more to be found :-)
Control: severity -1 minor
Control: tag -1 wontfix
Hi Diego,
Quoting Diego Roversi (2018-09-19 21:46:26)
> On Mon, 17 Sep 2018 19:34:00 +0200
> Jonas Smedegaard <jo...@jones.dk> wrote:
>
> > No wait, sorrym, not even that makes sense to me.
> >
> > Please describe exactly what failed before above change which succeeds
> > with that change applied. I.e. which uwsgi file paths were ignored
> > before which now gets included?
> >
>
> Yes, you are right. In the end after some more test, I found out that
> the problem is that if you create a new vm, install uwsgi, configure
> and such, the first time you try to start it silently fail:
[...]
> Jonas Smedegaard <jo...@jones.dk> wrote:
>
> > No wait, sorrym, not even that makes sense to me.
> >
> > Please describe exactly what failed before above change which succeeds
> > with that change applied. I.e. which uwsgi file paths were ignored
> > before which now gets included?
> >
>
> Yes, you are right. In the end after some more test, I found out that
> the problem is that if you create a new vm, install uwsgi, configure
> and such, the first time you try to start it silently fail:
> Sorry for the noise. The initial problem (can't open pid file) was
> caused by not having set the UWSGI_DEB_* variables, when I launched
> manually uwsgi.
>
> The more frustrating things is the difficult to debug this kind of
> problem (I also hit the bug #900174 during test, and having no
> autoload=true in default.ini would help), where uwsgi don't start
> but no significant output is given. I suggest to document the way to
> manually launch, that is very useful to troubleshooting. You can
> find in bug #900174, but I repost here:
>
> # UWSGI_DEB_CONFNAME=hello UWSGI_DEB_CONFNAMESPACE=app uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/hello.ini
Thanks for the clarification.
> caused by not having set the UWSGI_DEB_* variables, when I launched
> manually uwsgi.
>
> The more frustrating things is the difficult to debug this kind of
> problem (I also hit the bug #900174 during test, and having no
> autoload=true in default.ini would help), where uwsgi don't start
> but no significant output is given. I suggest to document the way to
> manually launch, that is very useful to troubleshooting. You can
> find in bug #900174, but I repost here:
>
> # UWSGI_DEB_CONFNAME=hello UWSGI_DEB_CONFNAMESPACE=app uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/hello.ini
I am sorry your debugging was distracted by bug#900174 - I have now
better understood that one and _that_ bug should be fixed now with
2.0.17.1-4 released a moment ago.
I disagree that bypassing init scripts and using some parts of them in
custom ways should be better documented: It _is_ already documented
inside those scripts you tried to use, and the way you use them is very
much _unsupported_ ways of using them.
I therefore flag this as wontfix.
Nevertheless I apprecicate your helping out here: It was instrumental in
pushing forward a fix for bug#900174! Hope you will continue to report
bugs against uwsgi - there are no doubt more to be found :-)
0 new messages