You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My backup system, which backs up my email with the email service stopped, doesn't finish/exit until its email report is delivered. I don't bring mail server backup until the backup is complete. Chicken/egg.
My intent is to run dma with the DEFER option set so it will accept the report email, and allow the backup command to exit so the email server can be started. The report email will then be delivered when the next dma -q runs. Right now, I have a sendmail -i process issued by the backup system that is waiting a long time. At least several hours before its eventually delivered.
The above seems a bit of a kludge, so I may just install Postfix on the backup server. Just trying to make the defaults of my new FBSD 14.0 install work as-is.
AMANDA, the backup utility, spawns off sendmail -i <recipient address> (dma) process that holds the parent process open until it the mail delivery succeeds.
My observation has been that the sendmail process remains running until the mail system comes up. A complicating factor is the mail system being backed up hosts the backup report recipient address.
Workflow:
Mail service is stopped on remote host
Backup begins, which includes mail system
Back up completes
Backup parent process spawns child process of sendmail -i <recipient address> (dma)
Mail delivery fails because mail service is still down.
The sendmail process remains running in the backup indefinitely causing the backup parent process to also remain running
dma will daemonize once the queue file has been written, which means that it'll fork into the background and the parent exits. Is there some special code that deals with process groups?
The same sendmail processes waiting behavior is generated by other services such as Nagios (monitoring). e.g. sendmail -i (dma).
It may just be something on this server. Its a new installation of FreeBSD 14.0. Maybe there's something about the default MTA setup that's causing sendmail to wait for delivery. If I find the answer, I'll post it here.
Activity
corecode commentedon Feb 27, 2024
i don't think so. the retry is exponential, i think.
cscottpnw commentedon Feb 27, 2024
Ok, thanks.
Anything stupid/dangerous about running a
dma -qevery 5 minutes via cron?corecode commentedon Feb 27, 2024
You should be fine, but it won't do anything. What are you trying to do?
cscottpnw commentedon Feb 27, 2024
My backup system, which backs up my email with the email service stopped, doesn't finish/exit until its email report is delivered. I don't bring mail server backup until the backup is complete. Chicken/egg.
My intent is to run dma with the
DEFERoption set so it will accept the report email, and allow the backup command to exit so the email server can be started. The report email will then be delivered when the nextdma -qruns. Right now, I have a sendmail -i process issued by the backup system that is waiting a long time. At least several hours before its eventually delivered.The above seems a bit of a kludge, so I may just install Postfix on the backup server. Just trying to make the defaults of my new FBSD 14.0 install work as-is.
corecode commentedon Feb 27, 2024
How does the backup system know that the report has been delivered? dma should exit with success once the queue file has been written.
cscottpnw commentedon Feb 28, 2024
AMANDA, the backup utility, spawns off
sendmail -i <recipient address> (dma)process that holds the parent process open until it the mail delivery succeeds.My observation has been that the sendmail process remains running until the mail system comes up. A complicating factor is the mail system being backed up hosts the backup report recipient address.
Workflow:
sendmail -i <recipient address> (dma)corecode commentedon Feb 28, 2024
dma will daemonize once the queue file has been written, which means that it'll fork into the background and the parent exits. Is there some special code that deals with process groups?
cscottpnw commentedon Feb 28, 2024
The same sendmail processes waiting behavior is generated by other services such as Nagios (monitoring). e.g. sendmail -i (dma).
It may just be something on this server. Its a new installation of FreeBSD 14.0. Maybe there's something about the default MTA setup that's causing sendmail to wait for delivery. If I find the answer, I'll post it here.
Thanks for your help!