Bug 219753 - www/fcgiwrap rc script fails to start.
Summary: www/fcgiwrap rc script fails to start.
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Rodrigo Osorio
URL:
Keywords: easy, patch
Depends on:
Blocks:
 
Reported: 2017-06-03 16:24 UTC by Shuichi KITAGUCHI
Modified: 2020-04-12 16:19 UTC (History)
5 users (show)

See Also:
0mp: maintainer-feedback? (rodrigo)


Attachments
Fix patch (373 bytes, patch)
2017-08-23 10:09 UTC, Toshimichi Masubuchi
no flags Details | Diff
fcgiwrap-wait-for-socket.patch (602 bytes, patch)
2017-09-03 12:35 UTC, Pavel Merdin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Shuichi KITAGUCHI 2017-06-03 16:24:49 UTC
when fcgiwrap_socket_mode or fcgiwrap_socket_owner or fcgiwrap_socket_group is set, rc script of fcgiwrap fails to start.

# service fcgiwrap start
Starting fcgiwrap.
chmod: /data/fcgi/wrap.sock: No such file or directory

In fcgiwrap_postcmd(), chmod/chown/chgrp is called but domain socket does not created yet.
If "sleep" is added before chmod/chown/chgrp in fcgiwrap_postcmd(), rc script succeeds.
Comment 1 Toshimichi Masubuchi 2017-08-23 10:09:24 UTC
Created attachment 185690 [details]
Fix patch

I reproduced it in my environment, so I tried creating a patch.
Comment 2 Pavel Merdin 2017-09-03 12:35:18 UTC
Created attachment 186028 [details]
fcgiwrap-wait-for-socket.patch

I propose a different patch. The idea is to wait for up to 4 seconds for the socket file to be created. That is done multiple times in a loop to avoid waiting for 4 seconds.
It works on my system (FreeBSD FreeBSD 11.0-RELEASE-p9 amd64, Intel Core2 Duo CPU E4500 @ 2.20GHz, 8GB RAM).
The patch makes the start script dependent on seq command (hope it's okay).
Comment 3 Shuichi KITAGUCHI 2017-09-03 13:32:19 UTC
(In reply to Pavel Merdin from comment #2)

I like this patch because I'm using "sleep 2" in my environment.
(In most cases "sleep 1" fix this problem, but sometimes fails on my server...)
Comment 4 Toshimichi Masubuchi 2017-09-03 13:57:49 UTC
(In reply to Pavel Merdin from comment #2)

+1
It's a good patch.
Comment 5 Nathan 2018-08-21 22:46:49 UTC
Is this still an issue?
Comment 6 Pavel Merdin 2018-08-22 07:47:22 UTC
(In reply to Nathan from comment #5)
Are you suggesting something else was done to fix the issue? It might work on super fast servers. But the root cause was that the file was expected to be there immediately after spawning the daemon process. That is just about trying to be lucky.
Comment 7 Mateusz Piotrowski freebsd_committer freebsd_triage 2018-08-22 10:18:16 UTC
(In reply to Pavel Merdin from comment #6)
I wonder if we could use sysutils/wait_on[1] instead of a shell loop. The timeout value could be controlled via some rc.conf variable.

[1]: https://www.freshports.org/sysutils/wait_on/
Comment 8 Pavel Merdin 2018-10-28 13:24:41 UTC
(In reply to Mateusz Piotrowski from comment #7)
Does it make sense to create a dependency for this port, that's the question. If the wait_on function is good it might be better for it to end up in the base system, so everybody can use it.
At the moment it does not look like this patch is going to make it into the port, so not sure it's worth spending more time on.
Comment 9 Mateusz Piotrowski freebsd_committer freebsd_triage 2018-10-29 14:11:25 UTC
You are right.

1. The base system would benefit from a tool which is capable of monitoring files change.
2. That patch is pretty similar to what is being done at the moment in various /etc/rc.d scripts in the base (for example auditd).

I'll try to get it committed.
Comment 10 Mateusz Piotrowski freebsd_committer freebsd_triage 2018-11-03 22:45:18 UTC
Comment on attachment 185690 [details]
Fix patch

Deprecate in favor of the other patch.
Comment 11 Mateusz Piotrowski freebsd_committer freebsd_triage 2018-11-03 22:54:02 UTC
Assign to the current maintainer.

rodrigo probably has more knowledge about this software than I do, anyway.
Comment 12 olaf 2020-01-30 07:39:20 UTC
Is this port abandoned? fcgiwrap still does not start. Even not on
tcp6:[::1]:9000
Comment 13 olaf 2020-01-30 07:42:43 UTC
(In reply to olaf from comment #12)
The patch from comment #2 does not work.
Comment 14 commit-hook freebsd_committer freebsd_triage 2020-04-12 16:18:30 UTC
A commit references this bug:

Author: rodrigo
Date: Sun Apr 12 16:17:50 UTC 2020
New revision: 531530
URL: https://svnweb.freebsd.org/changeset/ports/531530

Log:
  www/fcgiwrap: wait for fcgiwrap named socket creation before chown

  In certain circumstances postcmd function is called before
  named sockets be created by fcgiwrap, causing a startup
  failure. This change leave up to 5 seconds to fcgiwrap to
  properly start.

  Bump PORTREVISION.

  PR:		219753
  Reported by:	Shuichi KITAGUCHI <ki@hh.iij4u.or.jp>

Changes:
  head/www/fcgiwrap/Makefile
  head/www/fcgiwrap/files/fcgiwrap.in
Comment 15 Rodrigo Osorio freebsd_committer freebsd_triage 2020-04-12 16:19:55 UTC
Change committed, thanks.

Please don't hesitate to report if you still finding issues during fcgiwrap startup.