I would like to suggest a new server attribute. Please see the design document.
PBS can easily generate huge amount of emails for one user. This can be easily marked as spam or considered as same nasty behavior. The mail server can be blacklisted as a result, which is very unpleasant. We should be able to control this behavior.
The change offers the possibility to preprocess emails like some aggregation or ditching unnecessary emails. The preprocessing is supposed to happen outside PBS in an external script. It could do some smart things with emailsā¦
The example of the script will be a part of this change. I suggest to put it into the directory āunsupportedā. My initial ideas for the script are the following:
the mailer script will consist of two parts: the saver and the deamon
the server attribute āmailerā is supposed to be set to saver
the saver will save the email into simple sqlite db
the deamon will consume the emails from the db - check the db regularly for new emails and send them aggerated within a configurable time
the first email for a particular user will be sent immediately, subsequent emails will be aggregated and the whole bunch of emails will be sent in one email once for the configurable time
While this is nice, are we addressing the core issue that PBS generates email too often? Should we be changing the defaults to not send emails, and allow users to configure no-emails etc? On top of that, this feature u proposed can do the āfilterationā outside PBS of courseā¦
However, a confiugurable āmailerā is also possible today, by just using an alias or a symbolic link such that pbs invokes a custom script instead of āsendmailā (in other words use a sendmail wrapper) - does that not achieve the same effect?
yes, I would like to address sending too many emails from PBS, but I would like to preserve the possibility to notify the users. Some of our users like to use ā-m abeā for qsub and they have a huge amount of jobs. E.g.: They search through the emails on so onā¦ I do not want to disable the possibility to be notifiedā¦
I thought about not changing PBS code - just like you mentioned. The symlink would work but it would be lost on sendmail upgradeā¦
I donāt think the alias would work. Alias is for bash only. It will not work with execv(). Moreover, the default path to sendmail is absolute. So, the alias can not override it either. Am I missing something?
That is why I thought maybe we could make the mailer configurableā¦ If we conclude it is not a good idea, I still can configure the path to mailer via āāwith-sendmailā option to configureā¦ I just think that a configurable mailer could be convenient, but yes - I can address the issue without patching PBS.
Another possibility would be to hook an aggregation script in aliases for postfix. This would be also outside of PBS, and the path could remain the same. But it will affect the whole system and not only the pbs_server.
yes u are right vaclav, alias will not work in this case. I basically meant a wrapper. I like the change you are proposing with the server attribute. Letās go ahead with it. Thanks!