I run stunnel (version 5.00) as a non-root user which does not have write permissions to /var/run. So I created file /var/run/stunnel.log with right access for that user
-rw-r--r--. 1 stunnel stunnel 0 May 28 21:31 stunnel.pid
When I start daemon, it writes to logfile the following
2014.05.28 22:18:44 LOG3[8878]: Cannot create pid file /var/run/stunnel.pid 2014.05.28 22:18:44 LOG3[8878]: create: File exists (17)
It seems that it tries to create pidfile in /var/run, and ignores that the file is already exists. As a result, pid is not written to stunnel.pid, and daemon crashes. Could this be fixed?
On 29.05.2014 00:58, reg14@rambler.ru wrote:
It seems that it tries to create pidfile in /var/run, and ignores that the file is already exists. As a result, pid is not written to stunnel.pid, and daemon crashes. Could this be fixed?
You might want to note that PID files are *supposed* to *not* exist if the software in question is not currently running. Try creating a *subdirectory* that the user has sufficient rights for, and have stunnel put the PID file there.
Regards, J. Bern
On 28/May/2014 at 21:51:42 +0200, Jochen Bern wrote:
On 29.05.2014 00:58, reg14@rambler.ru wrote:
It seems that it tries to create pidfile in /var/run, and ignores that the file is already exists. As a result, pid is not written to stunnel.pid, and daemon crashes. Could this be fixed?
You might want to note that PID files are *supposed* to *not* exist if the software in question is not currently running. Try creating a *subdirectory* that the user has sufficient rights for, and have stunnel put the PID file there.
I did this way and discovered that stunnel does not remove pidfile on stopping if it has received SIGHUP during its session. PID does not change, stop is successful, but pidfile is not removed. Then it becomes impossible to determine whether stunnel is running or not. So reloading configuration makes a mess. I think that truncating pidfile in an init.d script is more reliable sign that service is stoped as compared with deleting pidfile. init.d sctipts are probably the more appropriate place to manipulate pidfile. All that a daemon should do is to create pidfile if it does not exist.
Stunnel should remove it on abnormal exit. It's customary. See here http://stackoverflow.com/questions/688343/reference-for-proper-handling-of-p... On May 28, 2014 5:48 PM, reg14@rambler.ru wrote:
On 28/May/2014 at 21:51:42 +0200, Jochen Bern wrote:
On 29.05.2014 00:58, reg14@rambler.ru wrote:
It seems that it tries to create pidfile in /var/run, and ignores that the file is already exists. As a result, pid is not written to stunnel.pid, and daemon crashes. Could this be fixed?
You might want to note that PID files are *supposed* to *not* exist if the software in question is not currently running. Try creating a *subdirectory* that the user has sufficient rights for, and have stunnel put the PID file there.
I did this way and discovered that stunnel does not remove pidfile on stopping if it has received SIGHUP during its session. PID does not change, stop is successful, but pidfile is not removed. Then it becomes impossible to determine whether stunnel is running or not. So reloading configuration makes a mess. I think that truncating pidfile in an init.d script is more reliable sign that service is stoped as compared with deleting pidfile. init.d sctipts are probably the more appropriate place to manipulate pidfile. All that a daemon should do is to create pidfile if it does not exist. _______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
On 28/May/2014 at 19:18:41 -0400, Brian Wilkins wrote:
Stunnel should remove it on abnormal exit. It's customary. See here http://stackoverflow.com/questions/688343/reference-for-proper-handling-of-p...
As I described in my previous message, the problem is that stunnel does not remove pidfile on *normal* exit if it received HUP signal.
Thanks for the link. You are probably right, removing pidfile on exit (if daemon has write access for /var/run) is a good convention. But ignoring the existing pidfile on statup is rather unusual. Discussion on the link tends to the point that there is no canonical way for handling pidfiles. So on the daemon level it would be desirable if this were as simple as possible.
If we are to follow Apache httpd, it will warn you that a PID file exists. I have also seen Tomcat fail to start because of a stale PID.
so take your pick
On Thu, May 29, 2014 at 9:07 AM, reg14@rambler.ru wrote:
On 28/May/2014 at 19:18:41 -0400, Brian Wilkins wrote:
Stunnel should remove it on abnormal exit. It's customary. See here http://stackoverflow.com/questions/688343/reference-for-proper-handling-of-p...
As I described in my previous message, the problem is that stunnel does not remove pidfile on *normal* exit if it received HUP signal.
Thanks for the link. You are probably right, removing pidfile on exit (if daemon has write access for /var/run) is a good convention. But ignoring the existing pidfile on statup is rather unusual. Discussion on the link tends to the point that there is no canonical way for handling pidfiles. So on the daemon level it would be desirable if this were as simple as possible.
(Sorry for the shot quoting+references, but only Brians reply to the mail I want to reply to made it to my mailbox ...)
On May 28, 2014 5:48 PM, reg14@rambler.ru wrote:
stop is successful, but pidfile is not removed. Then it becomes impossible to determine whether stunnel is running or not.
(As far as the GNU version of "kill" goes, a "kill -0 $PID" will tell you whether a process with that PID still exists; I've seen that used in some init.d scripts. Not foolproof, of course.)
I think that truncating pidfile in an init.d script is more reliable sign that service is stoped as compared with deleting pidfile. init.d sctipts are probably the more appropriate place to manipulate pidfile.
Heavens *no*! init.d etc. scripts that fail to actually remove the process they're supposed to stop exist. Also, terminating processes *without* going through "the appropriate" script is way too easy - from a typo in a "kill" command to ambiguities like "/etc/init.d/httpd vs. apachectl" to genuine abortion (SIGSEGV etc.) to things like the oomkiller running amok on a cluster we're setting up these days.
Regards, J. Bern
On 29/May/2014 at 18:54:50 +0200, Jochen Bern wrote:
On May 28, 2014 5:48 PM, reg14@rambler.ru wrote:
stop is successful, but pidfile is not removed. Then it becomes impossible to determine whether stunnel is running or not.
(As far as the GNU version of "kill" goes, a "kill -0 $PID" will tell you whether a process with that PID still exists; I've seen that used in some init.d scripts. Not foolproof, of course.)
Thanks for the tip. It is the way to determine if pidfile is stale. But chances are that the PID is already assinged to another process. So 'kill -0 $PID' is not definitely reliable.
Well, stunnel reload is not used very often so it may be excluded from the init script. Simple start/stop are probably enough.
-
Brian Wilkins -
Jochen Bern -
reg14＠rambler.ru