[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#685384: unblock: uwsgi/1.2.3+dfsg-3



Hi Adam,

On Mon, Aug 20, 2012 at 8:17 PM, Adam D. Barratt
<adam@adam-barratt.org.uk> wrote:
> On Mon, 2012-08-20 at 14:19 +0200, Janoš Guljaš wrote:
>> On Mon, Aug 20, 2012 at 2:17 PM, Adam D. Barratt
>> <adam@adam-barratt.org.uk> wrote:
>> > On 20.08.2012 12:37, Janos Guljas wrote:
>> >>
>> >> Please unblock package uwsgi.
>> >>
>> >> There is a bug with a release in Wheezy that is making init script
>> >> useless after a reload. The fix is to remove `name` parameter from
>> >> start-stop-daemon. I am sending debdiff.
>> >
>> > What name does the daemon end up running under?  (Presumably not "uwsgi".)
>>
>> The name is changed from uwsgi to uwsgi-core.
>
> If the daemon always runs as "uwsgi-core", would it be worth changing
> the calls to use "--name uwsgi-core" or similar, instead of dropping the
> use of --name entirely?  I'm pondering how likely it is that s-s-d will
> end up killing the wrong process if the daemon has died and the PID has
> been re-used.  Maybe I'm just overly paranoid.

The problem is that /usr/bin/uwsgi is a symlink made by alternatives
to /usr/bin/uwsgi-core, and uwsgi is keeping internally the binary
path of the path linked (got with readlink("/proc/self/exe", buf,
PATH_MAX)) and using it for reloads by sending the SIGHUP. After the
rerun with the link target the process is changing it's name to
uwsgi-core, or to whatever is set by alternatives for uwsgi group.

I agree that removing the name option can make more damage then good,
so I am sending debdiff with a patch that is changing how uwsgi_reload
function works. That function is overriding the main's argv[0] value
with a value provided by the readlink. The patch is just using argv[0]
in execvp as the first argument. That way the process name is
preserved, even if the path in argv[0] is in relative form.

Could review the changes from debdiff? If you have any suggestion I
would be glad to hear them. Package uwsgi_1.2.3+dfsg-4 is not uploaded
to the archive.

>
> Regards,
>
> Adam
>

Best,
Janos

Attachment: uwsgi_1.2.3+dfsg-2_uwsgi_1.2.3+dfsg-4.diff
Description: Binary data


Reply to: