blyman@spock.UUCP (Bill Lyman ) (04/16/88)
Okay I give up. I am trying to get a 3b2310 to call a machine between
1:00 am and 2:00 am in the morning. My System entry is as such.
Machine_name 0100-0200 ACU 1200 phone_no _________ etc
My poll statment is as follows
Machine_name 1
It is giving me messages that it is the wrong time to call. I have tried
2200-0300 and it stills say wrong time to call.
I am running 2.0.5
Can anyone tell me if I am doing something wrong.
Thanks Bill
yale!spock!blymanfriedl@vsi.UUCP (Stephen J. Friedl) (04/19/88)
In article <348@spock.UUCP>, blyman@spock.UUCP (Bill Lyman ) writes: > Okay I give up. I am trying to get a 3b2310 to call a machine between > 1:00 am and 2:00 am in the morning. My System entry is as such. > Machine_name 0100-0200 ACU 1200 phone_no _________ etc > My poll statment is as follows > Machine_name 1 > > It is giving me messages that it is the wrong time to call. I have tried > 2200-0300 and it stills say wrong time to call. This common problem is cause by cron not knowing how to export the proper TZ (timezone) environment variable; the default EST5EDT gets used. This can be fixed three ways: (1) move to New Jersey (2) get SVR3 -- it handles TZ correctly (3) put ". /etc/TIMEZONE" everywhere. Option (3) means you need to add the above line to the beginning of /usr/lib/uucp/uudemon.poll and /usr/lib/uudemon.hour if you are using the standard Poll scheme, or at the top of your shell scripts. There are other solutions to the incoming-mail-has-the-wrong-time problem, but that is for another day. MORAL: Always include ". /etc/TIMEZONE" at the start of scripts run from cron. -- Steve Friedl V-Systems, Inc. Wizard of undocumented 3B options friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
sullivan@vsi.UUCP (Michael T Sullivan) (04/20/88)
In article <559@vsi.UUCP>, friedl@vsi.UUCP (Stephen J. Friedl) writes: > In article <348@spock.UUCP>, blyman@spock.UUCP (Bill Lyman ) writes: > > Okay I give up. I am trying to get a 3b2310 to call a machine between > > 1:00 am and 2:00 am in the morning. My System entry is as such. > > Machine_name 0100-0200 ACU 1200 phone_no _________ etc > > This common problem is cause by cron not knowing how to export the > proper TZ (timezone) environment variable; the default EST5EDT gets > used. This can be fixed three ways: This is wrong (boss :-). I sent Bill mail on this but I saw this and decided to post. The problem is that he needs a day(s) of the week in front of his time. Example: machine Any0100-0200 ... machine Wk0100-0200 ... machine SuMoTu0100-0200 ... I used to get bitten by this all the time, but I'm catching it now. If you forget to put a day(s) of the week it will always be the wrong time to call. -- Michael Sullivan {uunet|attmail}!vsi!sullivan sullivan@vsi.com HE V MTL
rjd@occrsh.ATT.COM (04/20/88)
:This common problem is cause by cron not knowing how to export the :proper TZ (timezone) environment variable; the default EST5EDT gets :used. This can be fixed three ways: : : (1) move to New Jersey : (2) get SVR3 -- it handles TZ correctly : (3) put ". /etc/TIMEZONE" everywhere. : :Option (3) means you need to add the above line to the beginning :of /usr/lib/uucp/uudemon.poll and /usr/lib/uudemon.hour if you are :using the standard Poll scheme, or at the top of your shell scripts. :There are other solutions to the incoming-mail-has-the-wrong-time :problem, but that is for another day. : :MORAL: Always include ". /etc/TIMEZONE" at the start of scripts : run from cron. :-- :Steve Friedl V-Systems, Inc. Wizard of undocumented 3B options Well, it is much easier to have the script that starts cron on boot up to have the correct TZ variable. Just add ". /etc/TIMEZONE" before the /etc/cron line in whichever file starts cron for you; usually either /etc/rc.d/cron or /etc/rc2.d/S??cron. In this way, cron WILL have the correct TZ variable. Alternately, just put the ". /etc/TIMEZONE" on the first line in /etc/rc2 (for multi user run control). You see, its not a problem of cron not properly exporting the TZ variable, its a problem of cron NEVER being told what the right TZ variable is, so it assumes EST5EDT.... Incoming mail never having the right time is related to this in that /etc/TIMEZONE is never consulted here either (because uucico as a shell does not execute /etc/profile, normally the only place that /etc/TIMEZONE is consulted). Randy
friedl@vsi.UUCP (Stephen J. Friedl) (04/22/88)
In article <144800028@occrsh.ATT.COM>, rjd@occrsh.ATT.COM writes:
<
< Some time ago, I wrote:
<
< :This common problem is cause by cron not knowing how to export the
< :proper TZ (timezone) environment variable; the default EST5EDT gets
< :used. [...]
<
< Well, it is much easier to have the script that starts cron on boot
< up to have the correct TZ variable. Just add ". /etc/TIMEZONE" before
< the /etc/cron line in whichever file starts cron for you; usually either
< /etc/rc.d/cron or /etc/rc2.d/S??cron.
Not always. The 3B2 Sys V Rel 2.0.4 cron does not export TZ at all
even if it is told to do so in the manner mentioned above. The System
V Rel 3.1 (maybe r3.0) properly exports TZ in the manner suggested.
< /etc/TIMEZONE is never consulted here either (because uucico as a shell
< does not execute /etc/profile, normally the only place that /etc/TIMEZONE
< is consulted).
With 3B2 Sys V Rel. 3.1, /etc/TIMEZONE is consulted by init to export
the proper time to getty and uucico and other friends.
--
Steve Friedl V-Systems, Inc. Resident access(2) basher
friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedlwcs@skep2.ATT.COM (Bill.Stewart.<ho95c>) (04/24/88)
In article <559@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
:This common problem is cause by cron not knowing how to export the
:proper TZ (timezone) environment variable; the default EST5EDT gets
:used. This can be fixed three ways:
: (1) move to New Jersey
: (2) get SVR3 -- it handles TZ correctly
: (3) put ". /etc/TIMEZONE" everywhere.
:MORAL: Always include ". /etc/TIMEZONE" at the start of scripts
: run from cron.
If you can't use solution 1), remember to put . /etc/TIMEZONE into
/etc/rc BEFORE YOU START CRON. This way, all your cron jobs will know
what timezone it is. Also put it in /etc/profile, so people who use
normal shells to log in will get it. This still doesn't help incoming
uucp jobs, since uucico doesn't see /etc/profile; does it do the right thing?
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# skep2 is a local machine I'm trying to turn into a server. Please send
# mail to ho95c or ho95e instead. Thanks.kdavis@lamc.UUCP (Ken Davis) (04/26/88)
In article <66@skep2.ATT.COM> wcs@skep2.UUCP (46323-Bill.Stewart.<ho95c>,2G218,x0705,) writes: >This still doesn't help incoming >uucp jobs, since uucico doesn't see /etc/profile; does it do the right thing? >-- ># Thanks; ># Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs ># skep2 is a local machine I'm trying to turn into a server. Please send ># mail to ho95c or ho95e instead. Thanks. I use a pseudoshell for uucico logins called uucicotime : it follows: -------------------------cut here------------- #! /bin/sh # # Yes, I know the above probably won't help on a vanilla # S5 system, but it can't hurt, and on some S5 systems # it *will* work. # . /etc/TIMEZONE # forcibly set TZ # # Get around Bourne shell bug, present in all vanilla # Bourne shells prior to the S5R3 one, that causes "$@" # to expand to "", rather than nothing, if there are no # arguments to the script. # if [ $# != 0 ] then exec /usr/lib/uucp/uucico "$@" else exec /usr/lib/uucp/uucico fi ----------------------------- cut here ------------------------ -- Ken Davis - Letterman Army Medical Center - San Francisco, CA {pacbell,well,hoptoad}!lamc!kdavis kdavis@optimis-pent.arpa
ccea3@rivm.UUCP (Adri Verhoef) (04/27/88)
In article <1186@lamc.UUCP> kdavis@lamc.UUCP (Ken Davis) writes: >I use a pseudoshell for uucico logins called uucicotime : it follows: [...] > if [ $# != 0 ] > then > exec /usr/lib/uucp/uucico "$@" > else > exec /usr/lib/uucp/uucico > fi What you need here is: exec /usr/lib/uucp/uucico ${@+"$@"}