Bug 79120 - security/stunnel tries to create pid file in non-existent directory
security/stunnel tries to create pid file in non-existent directory
Status: Closed FIXED
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s)
Latest
Any Any
: Normal Affects Only Me
Assigned To: roam
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-22 10:50 UTC by jim.hatfield
Modified: 2005-05-12 12:37 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jim.hatfield 2005-03-22 10:50:01 UTC
portupgraded from stunnel 4.05 to 4.07. Saw the warning about rc_subr and added the stunnel_enable="YES" to /etc/rc.conf. Spotted that it wanted to put its pid file in /usr/local/var/stunnel rather than /var/run as before. However this directory does not exist - wasn't created by the installation.

Fix: 

Added 'stunnel_pidfile="/var/run/stunnel.pid"' to /etc/rc.conf and 'pid = /var/run/stunnel.pid' to /usr/local/etc/stunnel/stunnel.conf. Now works as before.
How-To-Repeat: portupgrade from stunnel 4.05 to 4.07 and check to see if /usr/local/var/stunnel has been created. Start and stop stunnel and see the pidfile warning.
Comment 1 Mark Linimon freebsd_committer 2005-03-22 21:43:01 UTC
Responsible Changed
From-To: freebsd-bugs->trevor

Reclassify and assign.
Comment 2 Mark Linimon freebsd_committer 2005-03-22 23:26:18 UTC
Responsible Changed
From-To: trevor->roam

Fix misassignment.  I _thought_ I did 'make maintainer' in the right 
directory ...
Comment 3 roam freebsd_committer 2005-03-23 12:11:54 UTC
State Changed
From-To: open->analyzed

I'm looking into this one, and into moving the pid file to /var/run, 
where it belongs...
Comment 4 roam freebsd_committer 2005-05-12 12:36:53 UTC
State Changed
From-To: analyzed->closed

Fixed in the just-committed update to 4.10. 
Thanks for the problem report and the analysis!
Comment 5 roam freebsd_committer 2005-05-12 12:36:53 UTC
State Changed
From-To: analyzed->closed

Fixed in the just-committed update to 4.10.  Thanks for the problem report!