On Thu, 7 May 2020 at 08:49, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote:
On 5/6/20 11:34 PM, Cameron Simpson wrote:
> On 07May2020 13:19, Cameron Simpson <cs@xxxxxxxxxx> wrote:
>> On 06May2020 20:20, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote:
>>> I am reading up on esmtp which comes with the base install and
>>> seemingly no mta needed?
>>>
>>> Anyway
>>> https://linux.die.net/man/5/esmtprc
>>>
>>> shows how to config for sending an email via esmtp to an mta, but
>>> not just local delivery...
>>
>> The bottom of that manual entry describes the "mta" setting, and says
>> that esmtp relies on a local MTA for local delivery (addresses
>> without an "@"). So you'll need something additional anyway. May as
>> well go straight to a proper MTA.
>
> And then, to my chagrin, I reread and see it provides example "mta"
> values like:
>
> /usr/bin/procmail -d %T
>
> So you may be good there.
Would first have to install procmail for this.
It would be interesting to find a 'simple' python script to grab the
cron output and 'make' an email and appended to the spool/mail
Mail is one of the areas where userd will add complexity. Having worked
in a large enterprise where mail leaving the intranet was tightly controlled,
my use of mail was limited to use cases like cron, at, and ad-hoc status
reports from our internal processing systems. It may be time to revisit the
use of mail for these use cases. Mail is often inconvenient for data analysis
like % of jobs that failed, reasons for failures (out of disk or memory space,
program crashed, network down, etc.) and trends in the time stats for jobs,
There are much fancier job scheduling systems that check for resources
before starting jobs, have a dashboard where you can see the status of
jobs (status of finished tasks, stats of running tasks, job queue with details
to explain why a particular job was delayed, etc.). One annoyance with
mail being locked down is that uses often miss notifications of problems.
When I retired, linux uses were moving to NUMA workstations where
there are issues around assigning cores to jobs to make best used of
cache and avoid long IPC hops, scheduling of GPU dependent jobs, etc.
With cron, some tasks need to pay attention to resource issues, so you
end up with a lot of ad-hoc hacks (kinda like the situation with init scripts).
SLURM is claimed to be suitable for NUMA workstations up to the
largest supercomuters. I have never used it myself, but it is available
in Fedora.
George N. White III
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
