KSH script won't email when nohup - email

I have a unique issue, i am in a unix environment and have a ksh script that ssh's to multiple sites, executes some code and then returns a response and then emails that response to an email address.
The script works perfectly when i run it, but since it must run for several hours i wish to nohup the script.
Here is where the problem is. When i nohup the script the email is not sent. I have scoured the boards looking for a reason or solution to no avail. if someone could point me in the right direction i would greatly appreciate it.
Here is my mail portion of the script:
mail -s "subject" email#address.com < /usr/etc/bin/mydir/infofile.out &&
rm -f infofile.out
exit;
EDIT: my environment is AIX 6.1.7.1

Finally figured out the answer, and even thou i was being dumb, i feel i have a responsibility to answer anyway, just in case someone else runs across this issue.
Turns out when i nohup my script it DOES send the email correctly. Its just that by nohuping and logging out it forces the email to be sent from the unix mail utility's default email address, and in my environment that address sends out hundreds of useless alerts, most of which i have filtered in outlook to go to a trash folder, well the email i was sending ended up in that trash folder.
Thanks to those who responded, especially shellter, your recommendation to use shell debugging is what let me know that it was sending from that default mail account.

Related

Sending simple email via MacOs 12 Terminal with mail (mail_version = 3.2.2)

I would like my MacOS "server" (basic mac mini with OS12.1 installed)
to be able to send emails using my current (paid) email provider.
Some theory first.
I am aware about this fine article (http://hints.macworld.com/article.php?story=20081217161612647)
What puzzles me is how on earth will "fresh out of box" mac be able to send even ONE email without being (mail-server) configured first. In other words to what email server will it send my email?
Discovered the very useful command mailq that will show the current status of all current emails being processed.
I understood that the command mail will send an email:
echo "this is the body" | mail -s "this is the subject" "myself#myserver.lu"
I understand, mail is using postfix in the background.
This will show the version of postfix (mine is mail_version = 3.2.2)
postconf mail_version
Is it possible to update postfix on macos?
Did anyone managed to enable the log on mail_version 3.2.2?
I get this warning:
postconf: warning: /etc/postfix/main.cf: unused parameter: maillog_file=/var/log/postfix.log
without the log it is a bit difficult to see what went wrong during email send...
thanks in advance for some MAC related input.

how to stop postfix MAILER-DAEMON emails

I am running Ubuntu 12.04 with Postfix
Late yesterday, I added a package (ispconfig3) that modified my postfix configuration and also added an entry to the root crontab that was invoking a script.
At around 11PM last night, I uninstalled that package and went to bed. The uninstall deleted the script and it's directory ok. But it did not clean up the crontab entry.
Since cron had trouble invoking the script, it sent root#xx.org an email. But ispconfig3 had modified my postfix configuration, therefore there is no mail transport capability. So a MAILER-DAEMON email was placed in the mail queue.
Overnight, (I'm guessing here!) cron wakes up every minute and tries to do the same thing. So by 7:00AM there are now 1100+ emails in the mail queue. But since postfix is messed up, I can't see them.
At around 8:00ish I realize that something is wrong with my email set up. I check postfix configuration, backout the changes and now I can get emails ok. I can send them, receive them, etc.
Then the flurry of emails start. Every minute or so, I get around 30 MAILER-DAEMON emails indicating that cron couldn't invoke the script. I check
sudo crontab -l
see the stale command for the non-existing script. I clear it out:
sudo crontab -e
I expect the emails to stop.
They don't.
In fact, every minute they seem to be increasing in number. I then spend a few hours looking at a ton of configuration files to try to figure out what is going on. By 11:00ish or so, it's up to 50+ emails coming in every minute.
I finally realized that this stream of emails was occurring because of the failures that occurred the night before and that it was going to go on for 7 days. The "7d" comes from a postfix configuration setting. (BTW I changed that to be "2d" i.e. only a couple of hours).
In any case, I solved it. I'm adding this post so others can save themselves some time. See below.
Finally hit on the idea to look at the mail queue.
A bit of googling and I found this site:
https://www.garron.me/en/linux/delete-purge-flush-mail-queue-postfix.html
I tried
postqueue -p
which listed all of the "(mail transport unavailable)" emails:
... snip ...
-- 1104 Kbytes in 1185 Requests.
I then did:
postqueue -f # this flushes the mail queue
postqueue -p
Mail queue is empty
And all of a sudden email flurry ended.
Note: the website above said to use:
postfix -f
that did not work for me. A bit of googling found the postqueue command.
Another note: I was worried there were emails in that mail queue that were not "mail transport unavailable", so I double checked all 1185 emails to ensure it was ok to purge them.

conditionally sending cron job emails

I'm not even sure if what I want is possible, but I'd like to run a Cron job where an email is only sent in certain conditions. I know that you can prevent mail from being sent at all by setting MAILTO to an empty string in the crontab file, but I've searched in several different ways, and can't find anything about sending email conditionally. My end goal is to run a Cron job that periodically checks whether the webserver is running, and if not, restart it. I only want an email if the webserver has to be restarted. I'm writing my Cron jobs in Perl. Is there a Perl command I can use within the job script that will disable the email in certain cases? Thanks for any help you can give me.
Cronjobs will send emails if the command you are running generate output. If you write your script to only send output to STDERR/STDOUT when you want an email, that should accomplish your goal.
There are 2 possibilities to send mails from cron jobs:
From program, that has been started by cron daemon,
From UNIX/Linux mechanism, that can send mail, if a program, that has been started as a cron job, has written something to STDOUT or STDERR.
I don't recommend to use the 2nd possibility. It is inflexible. You can't send mails to different recipients, depending on what alert has happened.
Usage of the 2nd way is rather a bad design. Cron jobs should redirect all their stdout and stderr to an idividual for every cron job log file for possible troubleshooting.
Perl possesses perfect possibilities to send mails, e.g. using MIME::Lite module.
This module is not a core one, so that you might should request sysadmin to install this module, if it's not available.
If you will use the 1st way, then your issue is easy to solve using Perl logic: just send the required mail from your Perl program after this program restarted the web server.

PHP mail() in dev environment: open the mail in a browser/editor instead of sending it?

On my machine I need to test the mails sent by my application. I'd rather avoid sending real mails.
Is there a way to have the email content showed to the screen a way or another, maybe by opening it in gedit or any text editor?
Maybe like replacing the commandline used to launch "sendmail"?
I am asking for Linux machines (Ubuntu more specifically).
Include a means of determining your environment in your project, or at least some kind of global variable that holds that information.
Then build an abstract mail interface that either sends real mails if it's running on a production server, but logs them to local files in case it runs on a dev machine / environment. As a logging package, I would recommend Monolog.
This would allow you to design the rest of your application (or at least the mail sending components) in a way that doesn't have to care about the environment.
After searching, here is the solution I came to:
create a script that will fake a smtp server
/usr/local/bin/sendmail-fake:
#!/bin/bash
{
date
echo $#
cat
} >> /var/log/sendmail-fake.log
configure PHP:
php.ini:
sendmail_path = /usr/local/bin/sendmail-fake
In this setup, emails are logged into a file. The script could be modified to open the content into a browser.
More details on the blog post.

failing while sending bug email in emacs

C-cC-c,get this info:
Sending...terminated by signal: Broken pipe
I find paste a long file in text mode is wrong(GUI version is OK),
and want to send a bug email.
what should i config? sending mail in emacs is cool!
thanks!
Emacs uses the /usr/sbin/sendmail command (specified by the sendmail-program variable) to deliver email you compose. You might be getting the error because your sendmail command is not working properly.
To resolve the issue you could try using the sendmail command directly (try man sendmail) to verify it really works. If it doesn't work properly, you should fix it and sending email from Emacs should start working.