When a hardening directive is the cause¶
A hardened systemd install exercises paths the container route never does, and when one of them fails the message rarely names the directive behind it. This page lists the failures that have actually been seen on a hardened bare-metal install, indexed by what they print, so that you can recognise one instead of going looking in the source.
All of them are corrected. Each entry names the test that holds the correction in place, so seeing the symptom again points at a regression in that specific behaviour rather than at your install. What the posture is meant to be is in Host hardening.
panic: config problem: mkdir /home/peart: permission denied¶
Printed during report generation, and it took the whole internal surface down with it, which then restarted and died the same way on the next attempt.
Two independent defects were stacked here. The PDF metadata step asked its toolchain for a configuration
directory under $HOME; the service account has no home directory and the unit carries ProtectHome=yes,
so the directory could not be created and the library panicked. And the report worker had no recovery, so
a panic in one job ended the process instead of that job.
Both are fixed. The metadata step no longer touches $HOME, and a job that panics now fails alone while
the queue keeps serving. Held by TestNormalizeMetadataWithoutAWritableHome, which points HOME at a path
that cannot be created, and by TestQueuePanicFailsOnlyItsOwnJob. Seeing it again means a regression in
the first of those.
chmod /var/lib/peart/work/<job>: operation not permitted¶
Printed while a report job was being prepared, before any rendering happened.
RestrictSUIDSGID=yes denies, by seccomp, any chmod whose mode carries the setgid bit, and the job
directory was being given setgid exactly that way. The fix was not to relax the directive. The renderer
stopped writing into the job directory altogether, the PDF now comes back over the connection that asked
for it, and the directory only has to be readable by the group, which it inherits without any chmod at
all.
Held by TestRendererWritesNothingInTheJobDirectory, and by TestCheckDirShare, which refuses a work root
that cannot hand its group down. Seeing it again means something in the code went back to asking the kernel
for setgid.
The sidecar is unreachable and its unit carries PrivateNetwork=yes¶
Less a message than a report that never renders while the service itself looks healthy.
With PrivateNetwork=yes the renderer has no network of its own, and it is reachable only because
peart-render.socket opens 127.0.0.1:8090 in the host's namespace and hands the descriptor over. If the
socket unit is not enabled, or if the service opened a listener of its own instead of inheriting the one it
was given, there is nothing to connect to. Verifying the install has the
three-step check, and the journal line is the giveaway: the sidecar says whether it is serving on a socket
it was handed or on one it opened itself.
Held by TestSidecarServesOnTheSocketItWasHanded, which performs the handover the way systemd does, with
descriptor 3 and LISTEN_FDS.
A report sits at "generating" after a restart¶
The queue lives in memory and the report row lives in the database, and nothing reconciled the two. A report whose job died with the process stayed pending for ever, while newly submitted reports generated normally around it.
At start-up, every report still pending is now marked failed, with a reason saying the generation was
interrupted and that it can be run again. Held by TestFailInterruptedReportsReconcilesTheOrphan, and the
audit entry it writes by TestMarkReportFailedAuditsTheFailure. Seeing it again means the reconciliation
did not run.
A failure this page does not list¶
If you hit one that a directive explains and this page does not name, report it rather than working around it. The posture is a promise, and a drop-in on your own host repairs your install while leaving the defect in place for everyone else. Note the exact message, which unit printed it, and the directive you suspect.