Restart after upgrade is an operations decision, reported by restart_pending.

php-fpm holds a pool of worker processes and the socket the web server is attached to. A restart throws away running requests.

RULE (dh-s6 >= 1.2.4, POD "Choosing between .noenable and .norestart"):
.noenable answers "first installation", .norestart answers "upgrade of a
running service" -- two questions, two files. .noenable ALONE already suffices
against a start on first installation, because dh-s6 only touches what
'svctl isenabled || svctl isup' affirms. So this file is not here "just to be
safe", but because the TIMING of the outage belongs to operations.

The state it produces -- new package, old process -- is invisible without
help. It is reported by the field restart_pending in aep-zabbix-checks
(>= 0.4.5), per unit, with a WARNING trigger after 1 h. Whoever removes this
file takes the choice away from operations; whoever keeps it must watch the
reporter.

CAUTION, common mistake: .norestart does NOT protect against a restart by
s6-rc-update. Measured on 24.09.2026: a STRUCTURAL change (dependencies,
bundles) restarts the affected longruns, even those nobody changed anything
on -- a dependency change on keepalived dragged cron along. That is why an
s6-policy upgrade on a hypervisor is a window, and this file does not help
against it.

This file is removed by dh_installs6 at build time and does NOT end up in the
package -- its content is pure documentation for the next session.
