Hi,


I have this case reported by a user.

There is a cronjob (placed under "/etc/cron.d/" directory) which sends emails:

Mail line in script (variables already set up):


There is no log found in "/var/log/maillog" when the script finishes. That is no emails are sent.

I checked the log for the cron job which looks fine to me:

When the script is run manually, the emails go fine.


What should I do next?

Use full paths in your notify_eqsendmail.sh script.

1 members found this post helpful.

The paths to mail and sendmail are included in the PATH for the user. I think we can set the PATH in the crontab too?

i think the $PATH variable gets set via .profile or .bash_profile when the user logs in. since the user is not logging in, the cron has no idea where the mail command is located.

1 members found this post helpful.

I had already set the PATH in a script under:

/etc/profile.d/

directory.

The cronjob has the option:

bash --login

which should say:

login and run the job/command.

...and since you're not taking the advice you've been offered (that is, putting the full path in your script), why bother asking us for advice? Modify the script...it'll take a few seconds, and you can see if it works, rather that arguing with folks about why it SHOULD work (yet obviously ISN'T).

1 members found this post helpful.

That is one example given. The developers here have got several of them. Some are working and some are not. If I could hand-change the script(s) I would not bother posting my question here at all.

for the one that isnt working can you add a line like this above where you call mail:to make sure you are using the expected program.

1 members found this post helpful.

Then why didn't you tell us any of this at the very start? How many scripts are there, which ones aren't working, and what's common between them? And WHY can't you 'hand-change' them?

can you sanitize (copy/paste) an example of one thats working and also one thats not working and annotate which user/system they are running from.

1 members found this post helpful.

TB0ne: -> I have learned a lot of things from you in the past. I request you to be calm down here.

Nothing not 'calm' about my question..why can't you answer it, and why didn't you provide complete details at the very beginning?

Instead of redirecting stdin and stderr to /dev/null, redirect it to a file. There's definitely error messages you're not seeing because of this.

1 members found this post helpful.

The problem with you here is: you have many "why's" which may not occur to one's mind at first.

Now, to answer your question:

I can't hand-change the scripts because they are not owned by me or by my group.

Secondly, the dve team does not want changes in the original scripts otherwise they would have to go through CAB process again. That is their problem - not mine. So, I was looking for a suitable solution or workaround for them. However, they do not seem to understand your/my points. This raises a question on how different teams within in organisation should co-ordinate with one another.


One of my seniors here in the organisation told me that if there is something we are supposed to know and we don't know they "the blame" is on us. If there is something they are supposed to tell us in advance and we don't ask still "the blame" is on us. Even if there is something they should know/understand and they don't try to know or understand.... my good friend.... "the blame" is still on us.

1 members found this post helpful.

The "whys" are because you didn't provide the details when you asked the question. You mentioned ONE script, with ONE problem...then come back and say it's several scripts, which you can't change. Both of which are VERY relevant to getting an answer, which should have occurred to you when asking the initial question.
...which you could have done without making comments previously.
...and if they're not your scripts, why are you maintaining/troubleshooting them?
...which is nothing that anyone here can help with. If a script is broken, you have two choices: fix it or live with it. There isn't a third option. Putting workarounds in does nothing but make things a maintenance nightmare later. Migrate to a new system and copy the scripts?? Won't that be nice...since NONE OF THEM WILL WORK, without modifying system config files. Get a new guy in to write a script? They won't be able to write a 'standard' script...since the 'workarounds' will make things more complicated, and make anything you do further on worse to document. And (essentially) having one team responsible for part of a script, and another responsible for the rest is just asking for headaches.

You were given advice by schneidz, and I agree with it. CRON does not inherit such things, and if you think about it, you'd see why. You're using "-login"...great...now, since cron does not have a user ID, how would it inherit things like paths/etc from the login profiles? Cron is a daemon...which is why scripts need full path names in them.
Not to sound harsh, but that's YOUR problem. There's nothing anyone here can do about the office politics at your company. If you don't like the policies at your company, pack up and get another job.

What we CAN address on this site is technical issues. The script is broken, and you say you're not allowed to fix it...so what's the point of the whole thread?