Use the serial comma:

facility, priority, and tag, respectively.

Why include the complexity of the and/or statement? That is not really relevant to this flag, which controls where the output goes, not which output. So maybe just

Redirect output from the daemonized process to

This is not a path (.Pa), but also seems unnecessarily redundant. The sentence can end after (0) and this part can be deleted:

or neither (0).

Please start new sentences on new lines.

Please start new sentences on new lines.
s/Default/The default/

Again, this is not a path, and seems redundant. Just

Log the output of the daemonized process to syslog.

Please avoid "the following", especially when the subject is immediately following:

These priorities are accepted: emerg, alert, crit, err, warning,

The default is 3, since neither the shell nor daemon(8) normally recognize things like STDOUT_FILENO.

appending

This is 4 more than 2**13. Is there a reason for this?

POSIX is clear that variables to communicate with asynchronous signal handlers should be volatile sig_atomic_t, not just sig_atomic_t.

However, if you restore the masking, normal variables will do.

If you #define SYSLOG_NAMES, <syslog.h> provides similar tables so you don't need to duplicate code.

Please keep the spaces here.

This can be made to work in the (admittedly unlikely) case that fd 1 and 2 are not open by closing pfd[0] before any dup2 and only closing pfd[1] if it is not equal to something it is to be dup2'ed to.

This wakes up every second for no reason, which the old version did not do. Keeping the signal masking from the old version and unmasking around async-signal safe read() allows using sigsuspend() or sigwait() here.

Perhaps, output should be collected into lines here.

Hmm, making outfile a file descriptor would lead to slightly less code.

The old code is not confused by unknown child processes but leaves them as zombies. I think the change to waitpid(-1 is good but successful return values other than pid should be ignored.

Example: (sleep 10 & exec daemon ...)

Needs bytes_read to be zeroed.

Would make much more sense to assert(len < LBUF_SIZE);. It's unlikely that the buffer size would exceed INT_MAX.

Probably we need to be extra careful here, because pid is -1 before forking. We wouldn't want to do kill(-1, SIGTERM)...

I think this can certainly be improved (e.g. optionally using procctl(PROC_REAP_ACQUIRE) and friends) but that should be in a later commit.

Common style is strcmp(...) == 0.

The latter four arguments pertain to where logs are going, and could be grouped into a structure to avoid dragging them along a few times.

An initializer is unnecessary here, and { 0 } might (wrongly) cause compiler warnings.

It would be wrong to retry after unknown errors, since the error would likely occur again immediately.

If the signal handler only switches between two different code paths, why not simply use one signal handler per signal? :)

Perhaps leave signals blocked during that time so there is never any question of races with pid.

But the second sentence is still on the same line...

The two handlers do indeed interfere, since calling waitpid() from the SIGCHLD handler invalidates the pid used by the SIGTERM handler (you'll get [ESRCH] or kill an unrelated process). The SIGTERM handler doesn't check for this yet (child_gone, probably, together with blocking SIGTERM before goto restart).

Note that this kind of PID reuse bug is inherent to the concept of pidfiles, but in this case it can be avoided.

Looks good. I don't care about the case where someone wants to pass through a closed fd 1 log what's written to fd 2 (in that case fd 1 will also be a copy of the pipe).

Why does this exit here as opposed to doing goto exit?

Should the file be unlinked on failure of daemon(3)?

Please not the above.

If the fcntl() call failed, then we would have left a potentially empty file hanging around. Perhaps the users wouldn't expect this. There might have been a scenario, where we succesfully open() a log file for appending with some previous contents or append to a file, where something else is also writing. In these cases at least, I would definitely avoid unlinking. I suppose by handling the FD leak prevention through open(... O_CLOEXEC) we don't have to worry about this, but please correct me if I'm wrong.

Yep, open() is easier and saves us the trouble of separately handling the possible (unlikely?) fcntl() failure.

The unlink was a minor point. I gave an example when it matters; daemon(3) call failing.

The actual point was the call to err as opposed to doing goto exit, which fails to clean up pidfiles.

Ah, that's exactly right. It would be better to attempt the log open() before opening the pid files.