Return to Answer

/usr/bin/mail performs a double fork to daemonize sendmail for sending the email. This sendmail proc gets reowned to init, so normally it wouldn't be affected by anything that happens with the original parent - except in the systemd case that reowned grandchild is still in the same cgroup as the original service. When systemd tears things down, it kills all processes within the cgroup, including the reowned sendmail process.

The mail command itself ran fine, but sendmail was getting killed by systemd before it had a chance to do its thing.

You can get around this by setting KillMode in the Unit section to process (the default is control-group). That will cause systemd to only kill the process which it directly fired.

Interestingly the way I stumbled upon this was through the use of strace. A normal strace revealed nothing, but the mail suddenly started working when using strace -f. strace -f was causing the main process to stick around until all of the children and grandchildren had wrapped up.

/usr/bin/mail performs a double fork to daemonize sendmail for sending the email. This sendmail proc gets reowned to init, so normally it wouldn't be affected by anything that happens with the original parent - except in the systemd case that reowned grandchild is still in the same cgroup as the original service. When systemd tears things down, it kills all processes within the cgroup, including the reowned sendmail process.

The mail command itself ran fine, but sendmail was getting killed by systemd before it had a chance to do its thing.

You can get around this by setting KillMode in the Unit section to process (the default is control-group). That will cause systemd to only kill the process which it directly fired.

Interestingly the way I stumbled upon this was through the use of strace. A normal strace revealed nothing, but the mail suddenly started working when using strace -f. strace -f was causing the main process to stick around until all of the children and orphaned grandchildren had wrapped up.

/usr/bin/mail performs a double fork to call sendmail for sending the email. This sendmail proc gets reowned to init, so normally it wouldn't be affected by anything that happens with the original parent - except in the systemd case that reowned grandchild is still in the same cgroup as the original service. When systemd tears things down, it kills all processes within the cgroup, including the reowned sendmail process.

The mail command itself ran fine, but sendmail was getting killed by systemd before it had a chance to do its thing.

You can get around this by setting KillMode in the Unit section to process (the default is control-group). That will cause systemd to only kill the process which it directly fired.

Interestingly the way I stumbled upon this was through the use of strace. A normal strace revealed nothing, but the mail suddenly started working when using strace -f. strace -f was causing the main process to stick around until all of the children and grandchildren had wrapped up.

/usr/bin/mail performs a double fork to daemonize sendmail for sending the email. This sendmail proc gets reowned to init, so normally it wouldn't be affected by anything that happens with the original parent - except in the systemd case that reowned grandchild is still in the same cgroup as the original service. When systemd tears things down, it kills all processes within the cgroup, including the reowned sendmail process.

The mail command itself ran fine, but sendmail was getting killed by systemd before it had a chance to do its thing.

You can get around this by setting KillMode in the Unit section to process (the default is control-group). That will cause systemd to only kill the process which it directly fired.

Interestingly the way I stumbled upon this was through the use of strace. A normal strace revealed nothing, but the mail suddenly started working when using strace -f. strace -f was causing the main process to stick around until all of the children and grandchildren had wrapped up.

/usr/bin/mail performs a double fork to call sendmail for sending the email. This sendmail proc gets reowned to init, so normally it wouldn't be affected by anything that happens with the original parent - except in the systemd case that reowned grandchild is still in the same cgroup as the original service. When systemd tears things down, it kills all processes within the cgroup, including the reowned sendmail process.

The mail command itself ran fine, but sendmail was getting killed by systemd before it had a chance to do its thing.

Interestingly the way I stumbled upon this was through the use of strace. A normal strace revealed nothing, but the mail suddenly started working when using strace -f. strace -f was causing the main process to stick around until all of the children and grandchildren had wrapped up.

/usr/bin/mail performs a double fork to call sendmail for sending the email. This sendmail proc gets reowned to init, so normally it wouldn't be affected by anything that happens with the original parent - except in the systemd case that reowned grandchild is still in the same cgroup as the original service. When systemd tears things down, it kills all processes within the cgroup, including the reowned sendmail process.

The mail command itself ran fine, but sendmail was getting killed by systemd before it had a chance to do its thing.

You can get around this by setting KillMode in the Unit section to process (the default is control-group). That will cause systemd to only kill the process which it directly fired.

Interestingly the way I stumbled upon this was through the use of strace. A normal strace revealed nothing, but the mail suddenly started working when using strace -f. strace -f was causing the main process to stick around until all of the children and grandchildren had wrapped up.