FTPD: shutdown waits up to ~5 s on idle sessions — getline() poll interval bounds FTPD_QUIESCE detection

[mgrossmann]

Summary

ftpd_session_getline() (src/ftpd#ses.c:177-204) polls the control socket with
a 5 s select() timeout and re-checks FTPD_QUIESCE on every timeout. That is
deliberate and it works — it is the fix that closed #2. What remains is the
residual boundary: an idle session only notices a shutdown at the next poll
expiry, so terminate() can wait up to ~5 s in cthread_manager_term() before
the last worker exits.

The delay is bounded and it is ~5 s in total, not 5 s per session — workers poll
concurrently. So this is a latency wart on /P FTPD and /F FTPD,SHUTDOWN, not
a hang. Recording it so it is tracked rather than rediscovered.

Current behaviour

tv.tv_sec = 5;
tv.tv_usec = 0;
rc = select(sess->ctrl_sock + 1, &rfds, NULL, NULL, &tv);
if (rc < 0)
    return -1;

if (rc == 0) {
    /* select() timed out -- check shutdown and idle */
    if (sess->server->flags & FTPD_QUIESCE)
        return -1;
    ...

The real idle timeout is measured cumulatively across 5 s rounds via
sess->idle_start, so the poll interval is independent of idle_timeout.

Why the mvsMF fix does not transfer directly

mvsMF solved the equivalent problem by checking the httpd quiesce flag on each
poll iteration and adding a 0.10 s delay. The first half is already present
here — the flag is checked on every poll.

The second half inverts. In the mvsMF case the 0.10 s delay made a busy poll
cheaper. In ftpd_session_getline() the select() is the blocking wait, so
lowering tv_sec 5 → 0.10 s does not add a delay, it removes one: it means
10 × SVC 75 per second per idle session, permanently, to save at most ~4.9 s
once at shutdown. On MVS 3.8j that trade is not worth making. Shortening the
poll is the wrong lever.

What the real lever is

Waking the blocked select() on demand, rather than shortening its timeout.
Both known mechanisms already have hazards documented in this repo:

• Post the wakeup ECB — ftpd.c:404-408 records that ecb_post alone does
  not reliably wake DYN75 selectex; SVC 75 uses its own internal wait rather
  than an MVS WAIT on the ECB.
• Close the socket under the worker — ftpd.c:391-396 records that closing
  a socket while another TCB holds it in select() can leave the TCP/IP control
  block undefined and hang select() indefinitely on 3.8j.

A third option is a self-pipe / loopback wakeup socket per session, added to the
fd_set, which shutdown writes one byte to. That costs one socket per session —
needs measuring against the memory budget before it is worth anything.

So this is research, not a one-liner.

Acceptance

• Shutdown latency attributable to idle worker sessions is materially below the
  current ~5 s, or
• the investigation concludes the current bounded 5 s is the right trade for
  3.8j and this issue is closed with that reasoning recorded.

Either outcome is fine. What is not fine is silently lowering the poll interval.

References

• BUG: cmd_shutdown() does not post wakeup ECB #2 — original shutdown hang; its resolution introduced the 5 s poll
• src/ftpd#ses.c:144-228 — ftpd_session_getline()
• src/ftpd.c:381-438 — terminate()

[mgrossmann]

Analysis 2026-08-12 — still present, and two premises above need correcting

Deferred past 1.0.0 — 1.0.0 ships with the current behaviour. Recording the
analysis so the next attempt does not restart from the wrong lever.

Still reproduces

Code unchanged since this was filed; only line numbers moved (#76, #8):

above	now
ftpd#ses.c:177-204	src/ftpd#ses.c:176-204
ftpd.c:404-408 (ecb_post note)	src/ftpd.c:451-455
ftpd.c:391-396 (close-socket note)	src/ftpd.c:437-443

1. The cost argument is inverted — select() does not block

libc370/src/dyn75/@@75sele.c is a wrapper:

int select(int maxsock, fd_set *r, ..., timeval *t) {
    return __75selx(maxsock, r, w, e, t, (void*)0);   /* selectex, NULL ECB list */
}

and @@75selx.c is a spin loop, not an MVS WAIT:

for(;;) {
    __75(&pl);                  /* subcode 4: polls, does not block */
    if (rc != -2) break;        /* socket ready */
    if (t) { if (wait==0) break; wait--; }
    if (ecblist) { ...ECB posted? -> goto check... }
    __asm__("STIMER WAIT,BINTVL==F'8'   0.08 seconds");
}

So an idle session already costs ~12.5 SVC 75 per second today — the 5 s
timeout is 62 poll rounds of 0.08 s, not one cheap wait. Shortening the poll
would not "add 10 SVC 75/s where there were none"; the extra cost would come
from per-call setup/teardown (subcodes 0/1/5/8 plus buffer alloc), not from
the polling. Shortening it is still the wrong lever, but not for the reason
recorded above.

2. The ecb_post hazard is specific to listening sockets

The reverted attempt (74a6218, backed out in bb57a26) built the ECB list
correctly for the convention in @@75selx.c:

ecblist[0] = (unsigned *)((unsigned)&server->wakeup_ecb | 0x80000000U);
ecblist[1] = NULL;

That it failed and the timeout failed at the same time has one economical
explanation: on a listening socket DYN75 does not return -2 from subcode 4
but waits internally, so the C loop never runs — neither its timeout
accounting nor its ECB check. One cause, both symptoms.

The control socket demonstrably behaves differently: the 5 s timeout there
does elapse, which is the premise of this whole issue — and that is only
possible if the C spin loop runs. The same loop checks the ECB list.

3. The lever

select() -> selectex() with a dedicated quiesce ECB. Zero additional
SVC 75 (the spin runs either way), wake-up <= 0.08 s instead of <= 5 s.

/* include/ftpd.h — server struct */
unsigned  quiesce_ecb;     /* posted once, never reset */

/* ftpd#ses.c — ftpd_session_getline() */
unsigned *ecbs[2];
ecbs[0] = (unsigned *)((unsigned)&sess->server->quiesce_ecb | 0x80000000U);
ecbs[1] = NULL;
...
rc = selectex(sess->ctrl_sock + 1, &rfds, NULL, NULL, &tv, ecbs);
/* an ECB post returns rc == 0 — falls into the existing QUIESCE branch */

/* ftpd#con.c:204 and ftpd.c:449 — every site that sets FTPD_QUIESCE */
ecb_post(&server->quiesce_ecb, 0);

It needs its own ECB, not wakeup_ecb: the accept loop clears that one on
every round (ftpd.c:385), so it is not a durable shutdown signal.

Leave tv.tv_sec = 5 as it is — after the fix it only governs idle-timeout
granularity, and a minimal diff is the better risk profile on 3.8j. Raising it
to 30 s to cut setup/teardown 6x is a separate question for a separate issue.

Verification is a measurement, not an assertion: idle session, /P FTPD,
measure console-command to termination message in SYSLOG. ~5 s before, <= 1 s
after. Falsifiable both ways.

4. Sibling, worse: PASV accept waits 30 s

ftpd#dat.c:233 waits for the PASV data connection with tv.tv_sec = 30. A
session parked there delays shutdown by up to 30 s — six times what this
issue describes. Same class of defect, so it is tracked here rather than
separately.

It is not safe to fix the same way. pasv_sock is a listening socket, i.e.
exactly the case where the ECB check is not reached per section 2. Before
touching it, measure whether those 30 s ever elapse at all: if DYN75 waits
internally, a client that never connects hangs the session indefinitely rather
than timing out after 30 s, and the 550 accept timeout path is dead code.
That measurement is the prerequisite for any change here.