That's exactly what a daemon parent is supposed to do: fork() a child into a detached state

Yes of course, a daemon closes all unnecessary file descriptors and forks itself and terminates, to detach from any terminal or I/O lines whatsoever. But in my book, the daemon does this right up front, before doing any other tasks.

But more to the point, I'm referring to the other child, then child resulting from the open($pipe, '-|', 'ip -o xfrm monitor')—that child.

Well, that child is kid of the daemons parent, so it might get reaped if grandfather exits. Perhaps reordering would help:

my $pipe;

my $pid = fork();

if (! defined $pid) {
    die "couldn't fork";
elsif ($pid > 0) {
    # write $pid to .pid file
    cleanup();
    exit(0);                 ## problem happens HERE
}

## now in sub-process
close(STDIN);
close(STDOUT);
close(STDERR);
...

# open the pipe in the child only after daemonizing
open($pipe, '-|', 'ip -o xfrm monitor') || die "couldn't start sub-com
+mand";

while (my $line = <$pipe>) {
   ...
}

close($pipe);
cleanup2();
exit(0);
[download]

Yes of course, a daemon closes all unnecessary file descriptors and forks itself and terminates, to detach from any terminal or I/O lines whatsoever. But in my book, the daemon does this right up front, before doing any other tasks.

It is usually desirable to have the parent do initialization and validation before forking, so it can report failure to the command-line at launch; otherwise, success or failure are indistinguishable without digging through the logs.

It is usually desirable to have the parent do initialization and validation before forking

...of which opening a pipe file handle from/to a forked sub-process arguably isn't part.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'