If we have large amounts of parallelism, pseudo can end up with too
many open connections and will no longer accept further connections,
hanging. This patch works around that by closing some clients, allowing
turnover of connections and unblocking the system. The downside is a small
but theoretical window of data loss. This is likely better than locking
up entirely though. Discussions with Peter are onging about how we could
better fix this.
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
---
.../pseudo/files/toomanyfiles.patch | 62 ++++++++++++++++++++++
meta/recipes-devtools/pseudo/pseudo_1.8.2.bb | 1 +
2 files changed, 63 insertions(+)
create mode 100644 meta/recipes-devtools/pseudo/files/toomanyfiles.patch
diff --git a/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
b/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
new file mode 100644
index 0000000..14a8975
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
@@ -0,0 +1,62 @@
+Currently if we max out the maximum number of files, pseudo can deadlock,
unable to
+accept new connections yet unable to move forward and unblock the other
processes
+waiting either.
+
+Rather than hang, when this happens, close out inactive connections, allowing
us
+to accept the new ones. The disconnected clients will simply reconnect. There
is
+a small risk of data loss here sadly but its better than hanging.
+
+RP
+2017/4/25
+
+Upstream-Status: Pending [Peter is aware of the issue]
+
+Index: pseudo-1.8.2/pseudo_server.c
+===================================================================
+--- pseudo-1.8.2.orig/pseudo_server.c
++++ pseudo-1.8.2/pseudo_server.c
+@@ -581,6 +581,7 @@ pseudo_server_loop(void) {
+ int rc;
+ int fd;
+ int loop_timeout = pseudo_server_timeout;
++ int hitmaxfiles;
+
+ clients = malloc(16 * sizeof(*clients));
+
+@@ -597,6 +598,7 @@ pseudo_server_loop(void) {
+ active_clients = 1;
+ max_clients = 16;
+ highest_client = 0;
++ hitmaxfiles = 0;
+
+ pseudo_debug(PDBGF_SERVER, "server loop started.\n");
+ if (listen_fd < 0) {
+@@ -663,10 +665,18 @@ pseudo_server_loop(void) {
+ message_time.tv_usec -= 1000000;
+ ++message_time.tv_sec;
+ }
++ } else if (hitmaxfiles) {
++ /* In theory there is a potential race
here where if we close a client,
++ it may have sent us a fastop message
which we don't act upon.
++ If we don't close a filehandle we'll
loop indefinitely thought.
++ Only close one per loop iteration in
the interests of caution */
++ close_client(i);
++ histmaxfiles = 0;
+ }
+ if (die_forcefully)
+ break;
+ }
++ hitmaxfiles = 0;
+ if (!die_forcefully &&
+ (FD_ISSET(clients[0].fd, &events) ||
+ FD_ISSET(clients[0].fd, &reads))) {
+@@ -688,6 +698,9 @@ pseudo_server_loop(void) {
+ */
+ pseudo_server_timeout =
DEFAULT_PSEUDO_SERVER_TIMEOUT;
+ die_peacefully = 0;
++ } else if (errno == EMFILE) {
++ hitmaxfiles = 1;
++ pseudo_debug(PDBGF_SERVER, "Hit max
open files, dropping a client.\n");
+ }
+ }
+ pseudo_debug(PDBGF_SERVER, "server loop complete [%d
clients left]\n", active_clients);
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
b/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
index b427b9a..9bcd031 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
@@ -7,6 +7,7 @@ SRC_URI =
"http://downloads.yoctoproject.org/releases/pseudo/${BPN}-${PV}.tar.bz
file://moreretries.patch \
file://efe0be279901006f939cd357ccee47b651c786da.patch \
file://b6b68db896f9963558334aff7fca61adde4ec10f.patch \
+ file://toomanyfiles.patch \
"
SRC_URI[md5sum] = "7d41e72188fbea1f696c399c1a435675"
--
2.7.4
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
