Cron job: TERM environment variable not set
Ivan Marsh
<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!"
Lew Pitcher
> 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
Ivan Marsh
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.
noi ance
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.
Ivan Marsh
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?
Chris F.A. Johnson
> On Thu, 10 Jul 2008 01:03:43 +0000, noi ance wrote:
>> 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
Bit Twister
> On Jul 9, 11:29 am, Ivan Marsh <ivanma...@yahoo.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.
Ivan Marsh
Nice.
There is a TERM variable set according to that script.
Bit Twister
> 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.
Ivan Marsh
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.
Bit Twister
>
> 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.
Ivan Marsh
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.
Bit Twister
> 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 -
Ivan Marsh
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.
Bit Twister
>
> 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
Ivan Marsh
Yep... that was it. Now I feel dumb.
Lew Pitcher
ITYM
if tty -s ;
then
clear
fi
Jim Diamond
UUOS. Tsk tsk, Lew.
Jim
sharewi...@gmail.com
Aragorn
following to alt.linux...
> Bit Tiwster, you put me on the right track. It is the command executed
> in the corn job which is giving that error and corn is just passing it
> in the email. Thank you.
2. The post you are replying to is from July 10th 2008. A little late,
wouldn't you say? I could be wrong but I even believe that Bit
Twister is no longer monitoring this newsgroup.
3. Use a real newsreader instead of Google Groups. Then you won't run
into this kind of old posts. Besides, the Google Groups posting
interface is badly broken, which is why most people filter out any
posts coming in through Google Groups.
--
= Aragorn =
http://www.linuxcounter.net - registrant #223157
Bit Twister
>
> 1. Don't top-post. Use interleaved replying.
> 2. The post you are replying to is from July 10th 2008. A little late,
> wouldn't you say? I could be wrong but I even believe that Bit
> Twister is no longer monitoring this newsgroup.
$ grep ':' .jnewsrc_esept | wc -l
78
shows I lurk around in several groups and skip the rest of
$ grep '!' .jnewsrc_esept | wc -l
31972
possible groups in eternal-september.org
> 3. Use a real newsreader instead of Google Groups. Then you won't run
> into this kind of old posts. Besides, the Google Groups posting
> interface is badly broken, which is why most people filter out any
> posts coming in through Google Groups.
Moe Trin
<slrnlt8m0d.t...@wb.home.test>, Bit Twister wrote:
>Aragorn wrote:
>> 1. Don't top-post. Use interleaved replying.
>I agree with that.
>> 2. The post you are replying to is from July 10th 2008. A little
>> late, wouldn't you say? I could be wrong but I even believe that
>> Bit Twister is no longer monitoring this newsgroup.
>You would be wrong. :)
> $ grep ':' .jnewsrc_esept | wc -l
> 78
[fermi ~]$ grep -c ':' .jnewsrc.motzarella
79
[fermi ~]$
>> Besides, the Google Groups posting interface is badly broken, which
>> is why most people filter out any posts coming in through Google
>> Groups.
>And I really agree with that suggestion.
% kill googlegroups.posts in 44 groups (out of 79 07/09/14)
Message-ID: googlegroups.com
Message-ID: JavaMail.geo-discussion-forums
I don't kill _all_ of the posts - but the 44 covers the more abused
groups. Also, if I'm replying to a google post in one of the remaining
groups, the reply will contain (above the referral line):
NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.
I no longer mention the late Blinky the Shark's web page, though last
I checked it was still available at
http://twovoyagers.com/improve-usenet.org/index.html
along with several other gems from Blinky.
Old guy
Aragorn
alt.linux...
> I globally kill googlegroups and webtv. I just don't have the
> time to spend on those posts anymore. I'm sure I throw away some good
> content as well, but it's nothing that's critical.
WebTV... Is that still around? :O