I actually found that flock has, for some reason, no effect whatsoever when
daemonize is used. (Is that fd inadvertently closed?)
This is on an ext4 filesystem. The related test configs: (the asdf lockfile was
pre-created)
$ cat x.ini
[uwsgi]
flock=asdf
socket=/tmp/test.sock
daemonize=foo.log
$ cat x-nodaemon.ini
[uwsgi]
flock=asdf
socket=/tmp/test.sock
First session, showing two daemonized uWSGIs and one non-daemonized uWSGI
starting concurrently with the same flock file:
$ uwsgi-1.4.3 x.ini
[uWSGI] getting INI configuration from x.ini
$ uwsgi-1.4.3 x.ini
[uWSGI] getting INI configuration from x.ini
$ ps aux | grep x.ini
21943 ... uwsgi-1.4.3 x.ini
21947 ... uwsgi-1.4.3 x.ini
$ uwsgi-1.4.3 x-nodaemon.ini
[uWSGI] getting INI configuration from x-nodaemon.ini
*** Starting uWSGI 1.4.3 (64bit) on [Tue Jan 15 09:50:39 2013] ***
And a second session, with two non-daemonized uWSGIs with the same lockfile:
(shell 1) $ uwsgi-1.4.3 x-nodaemon.ini
[uWSGI] getting INI configuration from x-nodaemon.ini
*** Starting uWSGI 1.4.3 (64bit) on [Tue Jan 15 09:51:23 2013] ***
(shell 2) $ uwsgi-1.4.3 x-nodaemon.ini
[uWSGI] getting INI configuration from x-nodaemon.ini
uWSGI ERROR: asdf is locked by another instance
(shell 2) $
Strange...
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Roberto De Ioris
Sent: Monday, January 14, 2013 9:23 PM
To: uWSGI developers and users list
Subject: Re: [uWSGI] pidfile + flock issues
> On Mon, Jan 14, 2013 at 10:04 AM, Roberto De Ioris <[email protected]>
> wrote:
>>
>>> Hey -
>>>
>>> I'm having some trouble with the pidfile = lockfile method discussed
>>> earlier on the #uwsgi IRC channel.
>>>
>>> Using custom-compiled (core buildconf) uWSGI 1.4.4 on Debian 6. My
>>> configuration is as follows (reduced to a minimal skeleton):
>>>
>>> [uwsgi]
>>> pidfile = /tmp/foo.pid
>>> flock = %(pidfile)
>>>
>>> and uWSGI dies with
>>>
>>> open("%(pidfile)"): No such file or directory [core/uwsgi.c line
>>> 3847]
>>>
>>> So firstly why isn't %(pidfile) being substituted with the actual
>>> pidfile
>>> value? (UWSGI_OPT_IMMEDIATE is to blame, I guess?)
>>> Substituting it manually in the INI then ends up with
>>>
>>> open("/tmp/foo.pid"): No such file or directory [core/uwsgi.c line
>>> 3847]
>>>
>>> most likely because /tmp/foo.pid doesn't exist yet. So I'm wondering
>>> whether something other than just O_RDWR should be passed to
>>> open() in uwsgi_opt_flock(), such as O_RDWR | O_CREAT...
>>> I'll be the first to admit that I'm not the best versed in POSIX
>>> semantics, so I don't know what untoward side effects that might have.
>>>
>>> Best,
>>>
>>> Aarni
>>> _______________________________________________
>>> uWSGI mailing list
>>> [email protected]
>>> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>>>
>>
>> Ok, i think using the pidfile as the lockfile is an unsolvable problem
>> (too much things will break) .
>>
>> Maybe the best bet is using the config file (it exists for sure ;) as
>> the
>> argument to flock.
>
> you can force opt resolution with something hackzy like this:
>
> # cat foo.ini
> ---------------------------------------------------
> [uwsgi]
> pidfile = /tmp/foo.pid
> if-opt = pidfile
> ini = exec://touch %(_)
> flock = %(_)
> endif = 0
>
> # example 2
> [foo]
> pidfile = /tmp/%x.pid
> ini = exec://touch /tmp/%x.pid
> flock = /tmp/%x.pid
> ---------------------------------------------------
>
> ... and run it like (example 1):
>
> # ./uwsgi --ini foo.ini -s@none
>
> ...or (example 2):
>
> # ./uwsgi --ini foo.ini:foo -s@none
>
> ... --pidfile is written to after flock stuff fires AFAICT, but it
> still doesnt work for some reason; in fact, uWSGI seems to be ignoring
> the advisory lock altogether for me (i am running uwsgi under and
> invocation of `flock`)
>
In one terminal:
./uwsgi --flock LICENSE -s :3032
In another:
./uwsgi --flock LICENSE -s :3032
the second one returns:
uWSGI ERROR: LICENSE is locked by another instance
Maybe you are on a nfs filesystem without locking capabailities ?
--
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
