#388 prosodyctl getpid tries to open pidfile for writing
Reporter
devurandom@gmx.net
Owner
MattJ
Created
Updated
Stars
★ (1)
Tags
Status-WontFix
Type-Defect
Priority-Medium
devurandom@gmx.net
on
getpid from util.prosodyctl tries to open the pidfile for writing (read and append), while reading alone seems to be sufficient. This creates a problem if the pidfile was not created by the prosody user. Attached patch fixes this.
{{{
--- prosody/util/prosodyctl.lua.orig 2014-01-23 20:19:32.000000000 +0100
+++ util/prosodyctl.lua 2014-01-23 20:18:58.000000000 +0100
@@ -194,7 +194,7 @@
return false, "no-posix";
end
- local file, err = io.open(pidfile, "r+");
+ local file, err = io.open(pidfile, "r");
if not file then
return false, "pidfile-read-failed", err;
end
}}}
MattJ
on
Hi, thanks for the report.
This is actually intentional (and maybe we should clarify it with a comment). It is so we can lock the file to see if Prosody has a lock on it or not.
See: https://hg.prosody.im/0.9/rev/1e287badd033
Changes
owner MattJ
devurandom@gmx.net
on
It worked fine here with above patch. Is a writable file handle really necessary to acquire a lock?
Zash
on
Testing suggest that the above patch should make it fail with "Bad file descriptor" and won't work unless the lfs.lock() call is also changed to "r".
MattJ
on
Closing this due to inactivity. It seems like the supplied patch is incomplete, but I'd still accept one with a fix for the issue Zash mentioned with tests.
getpid from util.prosodyctl tries to open the pidfile for writing (read and append), while reading alone seems to be sufficient. This creates a problem if the pidfile was not created by the prosody user. Attached patch fixes this. {{{ --- prosody/util/prosodyctl.lua.orig 2014-01-23 20:19:32.000000000 +0100 +++ util/prosodyctl.lua 2014-01-23 20:18:58.000000000 +0100 @@ -194,7 +194,7 @@ return false, "no-posix"; end - local file, err = io.open(pidfile, "r+"); + local file, err = io.open(pidfile, "r"); if not file then return false, "pidfile-read-failed", err; end }}}
Hi, thanks for the report. This is actually intentional (and maybe we should clarify it with a comment). It is so we can lock the file to see if Prosody has a lock on it or not. See: https://hg.prosody.im/0.9/rev/1e287badd033
ChangesIt worked fine here with above patch. Is a writable file handle really necessary to acquire a lock?
Testing suggest that the above patch should make it fail with "Bad file descriptor" and won't work unless the lfs.lock() call is also changed to "r".
Closing this due to inactivity. It seems like the supplied patch is incomplete, but I'd still accept one with a fix for the issue Zash mentioned with tests.
Changes