I have a cron job on one of my servers that sends a "Cron
<root@server-name> run-parts /etc/cron.daily" e-mail every morning with
the warning "TERM environment variable not set" in it.

I can't, for the life of me, figure out why it's sending it or how to get
it to stop. I'm not doing anything different on this server than I'm doing
on my other servers.

Any ideas?

--
"Remain calm, we're here to protect you!"

On Jul 9, 11:29*am, Ivan Marsh <ivanma...******.com> wrote:
> I have a cron job on one of my servers that sends a "Cron
> <root@server-name> run-parts /etc/cron.daily" e-mail every morning with
> the warning "TERM environment variable not set" in it.
>
> I can't, for the life of me, figure out why it's sending it or how to get
> it to stop. I'm not doing anything different on this server than I'm doing
> on my other servers.
>
> Any ideas?

Well, the error message implies that something is trying to manipulate
a terminal setting, like linespeed or text colour. Given that you are
running something from cron.daily, there is likely a script in /etc/
cron.daily that tries to access a terminal. Look through the /etc/
cron.daily scripts for some terminal-related command, like tset(1) or
stty(1)

HTH

On Wed, 09 Jul 2008 13:25:37 -0700, Lew Pitcher wrote:

> On Jul 9, 11:29*am, Ivan Marsh <ivanma...******.com> wrote:
>> I have a cron job on one of my servers that sends a "Cron
>> <root@server-name> run-parts /etc/cron.daily" e-mail every morning with
>> the warning "TERM environment variable not set" in it.
>>
>> I can't, for the life of me, figure out why it's sending it or how to
>> get it to stop. I'm not doing anything different on this server than
>> I'm doing on my other servers.
>>
>> Any ideas?
>
> Well, the error message implies that something is trying to manipulate a
> terminal setting, like linespeed or text colour. Given that you are
> running something from cron.daily, there is likely a script in /etc/
> cron.daily that tries to access a terminal. Look through the /etc/
> cron.daily scripts for some terminal-related command, like tset(1) or
> stty(1)

Well, it's telling me the problem is with the only script I've put out
there and I'm not doing anything in that script that has anything to do
with terminal settings. The most major thing the script does is run tar.

Very confusing.

--
"Remain calm, we're here to protect you!"

On Wed, 09 Jul 2008 15:33:06 -0500, Ivan Marsh typed this message:

> On Wed, 09 Jul 2008 13:25:37 -0700, Lew Pitcher wrote:
>
>> On Jul 9, 11:29Â*am, Ivan Marsh <ivanma...******.com> wrote:
>>> I have a cron job on one of my servers that sends a "Cron
>>> <root@server-name> run-parts /etc/cron.daily" e-mail every morning
>>> with the warning "TERM environment variable not set" in it.
>>>
>>> I can't, for the life of me, figure out why it's sending it or how to
>>> get it to stop. I'm not doing anything different on this server than
>>> I'm doing on my other servers.
>>>
>>> Any ideas?
>>
>> Well, the error message implies that something is trying to manipulate
>> a terminal setting, like linespeed or text colour. Given that you are
>> running something from cron.daily, there is likely a script in /etc/
>> cron.daily that tries to access a terminal. Look through the /etc/
>> cron.daily scripts for some terminal-related command, like tset(1) or
>> stty(1)
>
> Well, it's telling me the problem is with the only script I've put out
> there and I'm not doing anything in that script that has anything to do
> with terminal settings. The most major thing the script does is run tar.
>
> Very confusing.

Could it be that your script uses a $TERM variable which hasn't been set?

I mean cron jobs only understand environment variables set during boot,
any set during login aren't available.

On Thu, 10 Jul 2008 01:03:43 +0000, noi ance wrote:

> On Wed, 09 Jul 2008 15:33:06 -0500, Ivan Marsh typed this message:
>
>> On Wed, 09 Jul 2008 13:25:37 -0700, Lew Pitcher wrote:
>>
>>> On Jul 9, 11:29Â*am, Ivan Marsh <ivanma...******.com> wrote:
>>>> I have a cron job on one of my servers that sends a "Cron
>>>> <root@server-name> run-parts /etc/cron.daily" e-mail every morning
>>>> with the warning "TERM environment variable not set" in it.
>>>>
>>>> I can't, for the life of me, figure out why it's sending it or how to
>>>> get it to stop. I'm not doing anything different on this server than
>>>> I'm doing on my other servers.
>>>>
>>>> Any ideas?
>>>
>>> Well, the error message implies that something is trying to manipulate
>>> a terminal setting, like linespeed or text colour. Given that you are
>>> running something from cron.daily, there is likely a script in /etc/
>>> cron.daily that tries to access a terminal. Look through the /etc/
>>> cron.daily scripts for some terminal-related command, like tset(1) or
>>> stty(1)
>>
>> Well, it's telling me the problem is with the only script I've put out
>> there and I'm not doing anything in that script that has anything to do
>> with terminal settings. The most major thing the script does is run
>> tar.
>>
>> Very confusing.
>
> Could it be that your script uses a $TERM variable which hasn't been
> set?
>
> I mean cron jobs only understand environment variables set during boot,
> any set during login aren't available.

I'm not setting a $TERM variable anywhere. I assume there's one set at
boot... if not where should I set it? rc.local?

On 2008-07-10, Ivan Marsh wrote:
> On Thu, 10 Jul 2008 01:03:43 +0000, noi ance wrote:
....
>> Could it be that your script uses a $TERM variable which hasn't been
>> set?
>>
>> I mean cron jobs only understand environment variables set during boot,
>> any set during login aren't available.
>
> I'm not setting a $TERM variable anywhere. I assume there's one set at
> boot... if not where should I set it? rc.local?

You shouldn't.

A cron job does not operate in a terminal, so there should be no
references to $TERM in a script run by a cron job.

--
Chris F.A. Johnson, author | <http://cfaj.freeshell.org>
Shell Scripting Recipes: | My code in this post, if any,
A Problem-Solution Approach | is released under the
2005, Apress | GNU General Public Licence

On Wed, 09 Jul 2008 21:50:39 -0500, Ivan Marsh wrote:

> On Jul 9, 11:29Â*am, Ivan Marsh <ivanma...******.com> wrote:
> I have a cron job on one of my servers that sends a "Cron
> <root@server-name> run-parts /etc/cron.daily" e-mail every morning
> with the warning "TERM environment variable not set" in it.
>
> I'm not setting a $TERM variable anywhere.

Yep and the above cron message proves it.

It is some program being executed which is doing the complaint
and cron is passing the complaint along.


> I assume there's one set at boot...

No, it is normally set upon login.

> if not where should I set it?

If it has to be set, I would set it in a script with the program
requiring it set.

> rc.local?

No, cron does not know what has happened in start up scripts.

It might be instructive for you to write a little script which shows
you the cron environment. Here, try the following:

touch cron_set
chmod +x cron_set
echo '#!/bin/bash' > cron_set
echo 'set > /tmp/cron.environment' >> cron_set
echo 'echo $0 completed' >> cron_set

Verify that the cron_set script works with:
../cron_set
cat /tmp/cron.environment



Now you can either do a
cp cron_set /etc/cron_hourly
which will run cron_set upon the hour,
or you can use crontab to tell cron when you want cron_set to run via cron.

On Thu, 10 Jul 2008 10:24:19 +0000, Bit Twister wrote:

> On Wed, 09 Jul 2008 21:50:39 -0500, Ivan Marsh wrote:
>
>> On Jul 9, 11:29*am, Ivan Marsh <ivanma...******.com> wrote:
>> I have a cron job on one of my servers that sends a "Cron
>> <root@server-name> run-parts /etc/cron.daily" e-mail every morning
>> with the warning "TERM environment variable not set" in it.
>>
>> I'm not setting a $TERM variable anywhere.
>
> Yep and the above cron message proves it.
>
> It is some program being executed which is doing the complaint
> and cron is passing the complaint along.
>
>
>> I assume there's one set at boot...
>
> No, it is normally set upon login.
>
>> if not where should I set it?
>
> If it has to be set, I would set it in a script with the program
> requiring it set.
>
>> rc.local?
>
> No, cron does not know what has happened in start up scripts.
>
> It might be instructive for you to write a little script which shows
> you the cron environment. Here, try the following:
>
> touch cron_set
> chmod +x cron_set
> echo '#!/bin/bash' > cron_set
> echo 'set > /tmp/cron.environment' >> cron_set
> echo 'echo $0 completed' >> cron_set
>
> Verify that the cron_set script works with:
> ./cron_set
> cat /tmp/cron.environment
>
>
>
> Now you can either do a
> cp cron_set /etc/cron_hourly
> which will run cron_set upon the hour,
> or you can use crontab to tell cron when you want cron_set to run via cron.

Nice.

There is a TERM variable set according to that script.

--
"Remain calm, we're here to protect you!"

On Thu, 10 Jul 2008 10:11:16 -0500, Ivan Marsh wrote:

> Nice.
>
> There is a TERM variable set according to that script.

I would not have expected one to be set once it ran from cron.

I would like to see the output from the cron execution of the script.

There would be one set during the interactive execution of the script.

On Thu, 10 Jul 2008 15:58:00 +0000, Bit Twister wrote:

> On Thu, 10 Jul 2008 10:11:16 -0500, Ivan Marsh wrote:
>
>> Nice.
>>
>> There is a TERM variable set according to that script.
>
> I would not have expected one to be set once it ran from cron.
>
> I would like to see the output from the cron execution of the script.
>
> There would be one set during the interactive execution of the script.

Partial output when put in cron.hourly:

SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=3
TERM=dumb
UID=0
USER=root

So there is a TERM variable set.


--
"Remain calm, we're here to protect you!"

On Thu, 10 Jul 2008 13:20:44 -0500, Ivan Marsh wrote:
>
> Partial output when put in cron.hourly:

Was trying to make sure it was a cron dump, not a session dump.
$ wc -l /tmp/dump_env.log
31 dump_env.log

See, cron had 31 lines in it.
My session dump is over 100 lines.


> TERM=dumb
> So there is a TERM variable set.

Yes, I tested on my Mandriva linux install and it is set in mine also.
Both /bin/bash and /bin/sh.

I should have tested it myself before posting my ignorance. :-(

Only thing I can think of now, is some script/application tests $TERM
and if equal dumb, prints the message you see from cron.

If I had to find to offender, I would put an
echo $0
in every script executed via cron.

Then I would know the script to look at to find the offender.

On Thu, 10 Jul 2008 18:38:45 +0000, Bit Twister wrote:

> On Thu, 10 Jul 2008 13:20:44 -0500, Ivan Marsh wrote:
>>
>> Partial output when put in cron.hourly:
>
> Was trying to make sure it was a cron dump, not a session dump. $ wc -l
> /tmp/dump_env.log
> 31 dump_env.log
>
> See, cron had 31 lines in it.
> My session dump is over 100 lines.
>
>
>> TERM=dumb
>> So there is a TERM variable set.
>
> Yes, I tested on my Mandriva linux install and it is set in mine also.
> Both /bin/bash and /bin/sh.
>
> I should have tested it myself before posting my ignorance. :-(
>
> Only thing I can think of now, is some script/application tests $TERM
> and if equal dumb, prints the message you see from cron.
>
> If I had to find to offender, I would put an
> echo $0
> in every script executed via cron.
>
> Then I would know the script to look at to find the offender.

The e-mail sent by cron identifies the script that's causing the problem
as my backup script, which as I said does nothing but tar up directories.
All the default scripts in cron.daily run fine and cron doesn't produce
the e-mail warning if I remove my script from the directory.

I think I'm going to look at some of the default scripts and see if
there's something in there that looks like it might be necessary to
prevent the message.

--
"Remain calm, we're here to protect you!"

On Thu, 10 Jul 2008 13:46:39 -0500, Ivan Marsh wrote:

> The e-mail sent by cron identifies the script that's causing the problem
> as my backup script, which as I said does nothing but tar up directories.

Well you could put some debugging commands in the script, example:
cat my_backup
#!/bin/bash
set -x
(your code here)
set -

On Thu, 10 Jul 2008 18:38:45 +0000, Bit Twister wrote:

> On Thu, 10 Jul 2008 13:20:44 -0500, Ivan Marsh wrote:
>>
>> Partial output when put in cron.hourly:
>
> Was trying to make sure it was a cron dump, not a session dump. $ wc -l
> /tmp/dump_env.log
> 31 dump_env.log
>
> See, cron had 31 lines in it.
> My session dump is over 100 lines.
>
>
>> TERM=dumb
>> So there is a TERM variable set.
>
> Yes, I tested on my Mandriva linux install and it is set in mine also.
> Both /bin/bash and /bin/sh.
>
> I should have tested it myself before posting my ignorance. :-(
>
> Only thing I can think of now, is some script/application tests $TERM
> and if equal dumb, prints the message you see from cron.
>
> If I had to find to offender, I would put an
> echo $0
> in every script executed via cron.
>
> Then I would know the script to look at to find the offender.

Crap!... I think I just found it.

I have a "clear;" statement in the script that was there to clean up the
output while debugging. I wounder if that's what's doing it.

--
"Remain calm, we're here to protect you!"

On Thu, 10 Jul 2008 13:54:24 -0500, Ivan Marsh wrote:
>
> I have a "clear;" statement in the script that was there to clean up the
> output while debugging. I wounder if that's what's doing it.

Yep that would be my first guess.

code change would be

tty -s
if [ $? -eq 0 ] ; then # we are not running in cron, so,
clear
fi