No domain.conf update, old create/renew dates, SIGPIPE signal in log

[Snousmoumryk]

Steps to reproduce

FreeBSD 11.3
acme.sh v2.8.6

Webroot mode, multiple domains

Command line in script which is called via cron

#!/bin/sh
su -m acme -c '/<...>/acme.sh --cron --home /<...>/acme'

Debug log

Log file tail

...
-----END CERTIFICATE-----'
[] Found cert chain
[] _end_n='34'
[] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/<...>'
[] Cert success.
[] Your cert is in  /<...>/acme/example.tld/example.tld.cer 
[] Return code: 141
[] Error renew example.tld.

Actually certificates are renewed and could be deployed with no errors. All files in /<...>/acme/example.tld/ directory have their modification date updated (excluding example.tld.key).

But variables in example.tld.conf file

• Le_CertCreateTime
• Le_CertCreateTimeStr
• Le_NextRenewTimeStr
• Le_NextRenewTime

are not updated and contain old numbers.

How to eliminate SIGPIPE signal during acme.sh execution and get variables updated?

[Neilpang]

can you please provide log with --debug 2 ?

[Snousmoumryk]

can you please provide log with --debug 2 ?

Here is acme.sh.log.zip Attached log file starts when previous cron job skipped renew task.

Web server is based on the XigmaNAS project software (FreeBSD embedded).

[Snousmoumryk]

@Neilpang I did additional tests in Let's Encrypt staging environment. Original acme.sh and its two modified versions were run under three different conditions.

Modifications

• Mod 1: Debugging (xtrace) acme.sh 1st line #!/bin/bash -x
• Mod 2: Native FreeBSD interpreter (bash->sh) acme.sh 1st line #!/bin/sh

Conditions

• Cond 1: Simple call (no redirection) su -m acme -c '/mnt/dsk/services/acme/acme.sh --cron --test --home /mnt/dsk/services/acme'
• Cond 2: Call with STDOUT to file (>file) su -m acme -c '/mnt/dsk/services/acme/acme.sh --cron --test --home /mnt/dsk/services/acme' > /mnt/dsk/services/acme/debug-acme.log
• Cond 3: Call with STDERR to STDOUT, then to file (>file 2>&1) su -m acme -c '/mnt/dsk/services/acme/acme.sh --cron --test --home /mnt/dsk/services/acme' > /mnt/dsk/services/acme/debug-acme.log 2>&1

Test results		orig	xtrace	bash->sh
no redirection	SIGPIPE error	Not executed	No error
>file	No error, but cert in file	Not executed, empty file	No error, but cert in file
>file 2>&1	No error, but cert in file	No error, but cert in file	No error, but cert in file

Assumptions It looks as if acme.sh has an error with the output file descriptors at some point. And SIGPIPE error appears for the bash interpreter only, while for native FreeBSD sh this error does not exist.

[Neilpang]

@Snousmoumryk
Thanks for your report. I will take a look soon.

[Snousmoumryk]

@Neilpang I did some more tests to further investigate acme.sh strange behavior in XigmaNAS custom FreeBSD kernel environment. This time I used /dev/null redirection and two options for calling acme.sh using su and sudo.

Conditions

• Cond 1: Call with su and redirect acme.sh su -m acme -c '/mnt/dsk/services/acme/acme.sh --cron --test --home /mnt/dsk/services/acme > /dev/null'
• Cond 2: Call with su and redirect su su -m acme -c '/mnt/dsk/services/acme/acme.sh --cron --test --home /mnt/dsk/services/acme' > /dev/null
• Cond 3: Call with sudo and redirect acme.sh sudo -u acme sh -c '/mnt/dsk/services/acme/acme.sh --cron --test --home /mnt/dsk/services/acme > /dev/null'
• Cond 4: Call with sudo and redirect sudo sudo -u acme sh -c '/mnt/dsk/services/acme/acme.sh --cron --test --home /mnt/dsk/services/acme' > /dev/null

Test results		su	sudo
no redirection	SIGPIPE error	SIGPIPE error
acme.sh >	No error	No error
su/sudo >	No error	No error

Notes Additional info about test conditions specific to XigmaNAS FreeBSD instance.

1. Error after server start and call via cron.
2. No error if acme.sh runs in CLI.
3. Error after cron restart in CLI and call via cron.
4. No error after cron restart in XigmaNAS webUI and call via cron.

[Snousmoumryk]

@Neilpang After some discussion with XigmaNAS development team, it turns out the root cause of the issue is as follows.

1. FreeBSD local mail subsystem is not configured in XigmaNAS system by design.
2. At run time acme.sh script outputs some data (cert content) to STDOUT, which is not expected with --cron command line option.
3. System cron tries to send any of STDOUT and STDERR acme.sh output via mail, except it's redirected.
4. Because local mail is not configured, the mail utility, invoked by cron, dies while script is still running, which causes broken pipe (SIGPIPE) error.

A solid workaround is to redirect acme.sh script output to >/dev/null 2>&1.

It seems this issue is specific to XigmaNAS system only, otherwise there would be numerous issue reports in different use cases.