As before, I did not compile or test the code. There may be other issues.

content is allocated and freed but never used.

fd will never contain an error code; it's always a pointer value. When that pointer is NULL, it indicates an error and the error code is in errno. That's what you should be inspecting during error handling. To convert the integer errno into a useful message, something like strerror() will help.

As you discovered, inserting arbitrary text into a script can present serious issues. The simplest solution is to write the reminder's text to a separate file.

strcpy of optarg to text is unsafe and can overflow. You can use strncpy, but then must be careful to ensure that the string is always null-terminated. strlcpy is a simpler alternative, if available. However, the simplest alternative in this case is to not copy at all.

Not only do you not need to copy, you don't need to allocate either. The reminder's text has already been allocated storage during startup. It's in argv. The only thing you need to do is pass around the pointer. The default value has also been stored away in the executable's image and it's location can also be passed around.

You implied that you are no longer waiting in the parent, but since the code is still there, a couple of notes about it.

You should always check WIFEXITED before using WEXITSTATUS (as you did with WIFSIGNALED before using WTERMSIG). An implementation is not forbidden from overloading bits for signal and status information (though I don't know if any implementation actually does so).

For portability and readability (especially for readability), it's a far better choice to use the macros in signal.h. Instead of 6, use SIGABRT. As far as I know, even though the kill(1) utility is required to recognize -6 as SIGABRT, nothing requires the kill(2) system call implementation to equate 6 with SIGABRT (although it almost certainly does).

Regarding your interprocess communication question, your pid file idea seems perfectly reasonable.

Regards,
Alister