Re: cron job verification

2005-02-02 Thread Derek Martin
On Wed, Feb 02, 2005 at 08:41:23PM -0500, Bill Sconce wrote:
> P.P.S.  On many systems if you do an "ls -l /bin/sh" you'll find that
> this isn't an actual executable but a symbolic link.  On my (Debian)
> systems it's a symbolic link which points to   ...surprise, bash:

Sure.  But I think it's important to realize that bash behaves
differently when invoked as sh than it does when invoked as bash...

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.



pgp2y6eGBcHF2.pgp
Description: PGP signature


Re: cron job verification

2005-02-02 Thread Michael ODonnell


> If I'm not mistaken, If #!/bin/sh is used the shell will use
> what is set for the user variable $SHELL when a user logs in.

You're mistaken.  The value of your $SHELL variable has
nothing to do with which interpreter handles a given
script when that script is directly "executed" by the
kernel.  Linux perpetuates the classic UNIX behavior for
"Miscellaneous Interpreters" in this matter: if a file
is marked executable but is determined to NOT be a native
binary, the hash-bang directive (if found at the beginning
of the file) will be honored blindly.

So, if you put "#!/bin/sh" at the beginning of a script
and hope to execute it "directly" [eg.  via exec()] there
had better be a /bin/sh in your filesystem because that's
the only interpreter that will be loaded for that script.

$SHELL comes into play in other situations, typically when
you're inside some other app and you want to execute an
arbitrary system command.  In situations like that the
app in question will often honor your $SHELL variable and
attempt to use that to execute any command line you specify.
 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-02-02 Thread Bill Sconce
On Wed, 2 Feb 2005 18:19:48 -0500
Ed Robitaille <[EMAIL PROTECTED]> wrote:

> On Wed, 2 Feb 2005 10:45:31 -0500
> Bob Bell <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Jan 12, 2005 at 12:15:46AM -0500, Derek Martin wrote:
> > >   #!/bin/sh
> > >   # NEVER start shell scripts as #!/bin/bash -- it can lead to strange
> > >   # and unintended results.
> > 
> > Like what?  I've never had a problem.  If I specifically am using bash
> > features, I always say "/bin/bash", as "/bin/sh" could mean Bourne shell
> > or POSIX shell.

> If I'm not mistaken, If #!/bin/sh is used the shell will use what is set for
> the user variable $SHELL when a user logs in. I use zsh and have SHELl set 
> for /bin/zsh.


A little more information on just the shebang ("!#") part of things.

When an executable file is invoked it's the kernel which figures out how
to run it.  If the magic "!#" line appears at the front of the file the
kernel passes the file to whatever the magic "!#" line points to (in the
case under discussion, to /bin/sh).  The SHELL environment varible isn't 
involved.  Indeed, no shell is involved at all.  (Not in interpreting the 
shebang - in the case under discussion a shell is _pointed to_ by the 
shebang, though, which is potentially confusing.)

Aside: the usual "scripting" case doesn't present the shell confusion:

#!/usr/bin/python
print 'Hello World'

..which causes the contents of the file following the shebang line to be
executed by the handler specified by the shebang line.  See?  No shell.

I believe the SHELL environment variable is primarily there to tell you
(or your scripts) what shell you (or they) are running under.  Someone
may correct me on that.

HTH
-Bill

P.S.  As for the shell you get when you log in, it's specified in
/etc/passwd.

P.P.S.  On many systems if you do an "ls -l /bin/sh" you'll find that
this isn't an actual executable but a symbolic link.  On my (Debian)
systems it's a symbolic link which points to   ...surprise, bash:

$ ls -l /bin/sh
lrwxrwxrwx1 root root4 May 10  2003 /bin/sh -> bash
$

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-02-02 Thread Kevin D. Clark

Ed Robitaille writes:

> If I'm not mistaken, If #!/bin/sh is used the shell will use what is
> set for the user variable $SHELL when a user logs in. I use zsh and
> have SHELl set for /bin/zsh.  

If what you say is true, why when you run a /bin/sh script doesn't
exec run your shell scripts through /bin/zsh?  After all, you set
SHELL to /bin/zsh.

I think that the resulting havoc would be kindof amusing.


Suggestion:  the bash man page has a lot of good material on this
topic.


> The predominant scripting $SHELL seems to be bash.

I disagree.  The Bourne Shell would be my answer.

Regards,

--kevin
-- 
GnuPG ID: B280F24E And the madness of the crowd
alumni.unh.edu!kdc Is an epileptic fit
   -- Tom Waits
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-02-02 Thread Ed Robitaille
On Wed, 2 Feb 2005 10:45:31 -0500
Bob Bell <[EMAIL PROTECTED]> wrote:

> On Wed, Jan 12, 2005 at 12:15:46AM -0500, Derek Martin wrote:
> >   #!/bin/sh
> >   # NEVER start shell scripts as #!/bin/bash -- it can lead to strange
> >   # and unintended results.
> 
> Like what?  I've never had a problem.  If I specifically am using bash
> features, I always say "/bin/bash", as "/bin/sh" could mean Bourne shell
> or POSIX shell.
If I'm not mistaken, If #!/bin/sh is used the shell will use what is set for 
the user variable $SHELL when a user logs in. I use zsh and have SHELl set for 
/bin/zsh.
The predominant scripting $SHELL seems to be bash.
Ed

> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
> 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-02-02 Thread Michael ODonnell



>   rsync 
>   if ! $? ; then
> echo -e "\nrsync completed successfully!\n"
>   else
> echo -e "\nrsync failed!\n!"
>   fi


BTW, it's legit (and sometimes clearer) to do it like this:

   if rsync 
   then
   echo -e "\nrsync completed successfully!\n"
   else
   echo -e "\nrsync failed!\n!"
   fi
 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-02-02 Thread Derek Martin
On Wed, Feb 02, 2005 at 01:47:14PM -0500, Mark Komarinski wrote:
> > If you invoke bash as /bin/bash, it will source all your environment
> > files (usually just your .bashrc, since normally it won't be invoked
> > as a login shell in this manner).  This can cause unintended effects.
>  
> Based on systems I used to admin, it's best to have your .bashrc and .cshrc
> exit immediately if it isn't an interactive login.  The reason we
> ran into was a user who wanted to scp a file, but it always failed.  

You're right that this can be a problem, I've run into that one before
as well.

There is another solution to this problem, which is IMO better.
Sometimes, you want your bashrc to be sourced...  I set a variety of
variables in my .bashrc that I would generally want scripts to know
about, including time zone and locale settings, for example.

To eliminate the problem you describe, I put login commands which
would generate output into .profile, and non-output-generating
commands in my .bashrc file.

Now, .profile is sourced when the shell is both interactive and a
login shell... otherwise .bashrc is sourced (see the bash man page,
INVOCATION section for specific details).  In order to make sure the
stuff in .bashrc is sourced for interactive login shells, my .profile
explicitly sources it.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.



pgpqyyHvmM7Cn.pgp
Description: PGP signature


Re: cron job verification

2005-02-02 Thread Mark Komarinski
On Wed, Feb 02, 2005 at 01:34:01PM -0500, Derek Martin wrote:
> On Wed, Feb 02, 2005 at 10:45:31AM -0500, Bob Bell wrote:
> > On Wed, Jan 12, 2005 at 12:15:46AM -0500, Derek Martin wrote:
> > >   #!/bin/sh
> > >   # NEVER start shell scripts as #!/bin/bash -- it can lead to strange
> > >   # and unintended results.
> > 
> > Like what?  I've never had a problem.  If I specifically am using bash
> > features, I always say "/bin/bash", as "/bin/sh" could mean Bourne shell
> > or POSIX shell.
> 
> If you invoke bash as /bin/bash, it will source all your environment
> files (usually just your .bashrc, since normally it won't be invoked
> as a login shell in this manner).  This can cause unintended effects.
 
Based on systems I used to admin, it's best to have your .bashrc and .cshrc
exit immediately if it isn't an interactive login.  The reason we
ran into was a user who wanted to scp a file, but it always failed.  Turned
out that scp would use ssh to start a shell on the remote side and execute
the .cshrc which would output data and corrupt the scp stream.

I don't have access to the machines in question anymore, so I don't remember
what the code was.  Google should be able to assist the curious.

-Mark


signature.asc
Description: Digital signature


Re: cron job verification

2005-02-02 Thread Derek Martin
On Wed, Feb 02, 2005 at 10:45:31AM -0500, Bob Bell wrote:
> On Wed, Jan 12, 2005 at 12:15:46AM -0500, Derek Martin wrote:
> >   #!/bin/sh
> >   # NEVER start shell scripts as #!/bin/bash -- it can lead to strange
> >   # and unintended results.
> 
> Like what?  I've never had a problem.  If I specifically am using bash
> features, I always say "/bin/bash", as "/bin/sh" could mean Bourne shell
> or POSIX shell.

If you invoke bash as /bin/bash, it will source all your environment
files (usually just your .bashrc, since normally it won't be invoked
as a login shell in this manner).  This can cause unintended effects.

I ran into this problem when I installed Debian 2.2 on one of my
systems.  When I logged into the system, IIRC X started up but I
couldn't do anything in any of the xterms I started...  That is, I
never got a prompt, and the system came to a grinding halt.  I was
able to log in at a virtual console and see what was going on.

In my .bashrc file, I had some code that used the which command to set
some variables.  On Debian 2.2, the which command was a shell script
which was invoked as #!/bin/bash.   This was causing an infinte loop,
where a bazillion /usr/bin/which processes were running and not
completing.

IIRC the most bizarre part of this was that if I logged in (as myself)
on the console, the effects were different than if I logged in under
X.  I was never able to determine why.  Note that I set the resource

  XTerm*loginShell:   true

in my .Xdefaults file, so there should be no difference (that I can
think of) between my xterm shells and one started on a VC.

> >   rsync 
> >   if ! $? ; then
> > echo -e "\nrsync completed successfully!\n"
> >   else
> > echo -e "\nrsync failed!\n!"
> >   fi
> 
> That won't work.  As you said, $? will evaluate to an integer, which the
> shell will then (unsuccessfully) try to execute.  You want either:

You're right, sorry!  My shell coding is a bit rusty these days.  :(
This is the one I meant:

> if [ $? -eq 0 ] ; then

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.



pgpXPIKSxdCpV.pgp
Description: PGP signature


Re: cron job verification

2005-02-02 Thread Ed Lawson
On Wed, 2 Feb 2005 10:45:31 -0500
Bob Bell <[EMAIL PROTECTED]> wrote:


> That won't work.  As you said, $? will evaluate to an integer, which
> the shell will then (unsuccessfully) try to execute.  


I tried to use the script and it failed for the reasons you stated.
Gives an erroneous report as a result.

Ed Lawson
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-02-02 Thread Bob Bell
On Wed, Jan 12, 2005 at 12:15:46AM -0500, Derek Martin wrote:
>   #!/bin/sh
>   # NEVER start shell scripts as #!/bin/bash -- it can lead to strange
>   # and unintended results.

Like what?  I've never had a problem.  If I specifically am using bash
features, I always say "/bin/bash", as "/bin/sh" could mean Bourne shell
or POSIX shell.

>   rsync 
>   if ! $? ; then
> echo -e "\nrsync completed successfully!\n"
>   else
> echo -e "\nrsync failed!\n!"
>   fi

That won't work.  As you said, $? will evaluate to an integer, which the
shell will then (unsuccessfully) try to execute.  You want either:

if rsync  ; then

or

if [ $? -eq 0 ] ; then

or it's ilk.

- Bob
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-01-11 Thread Derek Martin
On Tue, Jan 11, 2005 at 10:37:04AM -0500, Ed Lawson wrote:
> I have several cron jobs that I have written to sync various
> directories and to do backups.  I did this via crontab -e as root.
> My question is how do I verify the operation of the these jobs. I
> thought there would be mail sent to root or its alias upon completion,
> but there is none.

Cron normally only produces e-mail if the script/command you ran had
output.  The mail will go to the user as which the commands ran, in
this case root.

> What is the best way to receive verification or otherwise check on
> whether or not the job ran and if it ran to completion properly? 

Well, rsync conveniently provides an exit status which indicates its
success or failure, which you can use to good effect.  Wrap your cron
job in a shell script, which looks something like this:

  #!/bin/sh
  # NEVER start shell scripts as #!/bin/bash -- it can lead to strange
  # and unintended results.

  rsync 
  if ! $? ; then
echo -e "\nrsync completed successfully!\n"
  else
echo -e "\nrsync failed!\n!"
  fi

  # end of script

$? is always an integer which holds the exit status of the last
completed command (so there's never a need to put it in quotes, unless
you want to be sure the shell will treat it as a string).  The if
statement basically says if the exit status is zero (success),
indicate success.  Otherwise indicate failure.  The ouput should be
mailed to root.  There are a variety of ways to make your normal user
account get this mail, but the best is to simply alias root to your
normal account, as mentioned by someone else.

HTH!

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.



pgpoq255f4onG.pgp
Description: PGP signature


Re: cron job verification

2005-01-11 Thread Jason Stephenson
Larry Cook wrote:
On my Debian boxes, cron jobs send me an email if and only if they have
any output.  

Also on RedHat 8 and Solaris.  I would guess that is the standard 
behavior for all distros.
Also on Solaris, HP-UX, *BSD, etc. It's the standard for cron on UNIX or 
any UNIX-like OS.

Also, I believe the
mails are sent to root; I have an entry in /etc/aliases which actually
sends it to my normal user account.

I think it is sent to the account that owns the crontab file, which 
would be the account you did the "crontab -e" from.  If I want email to 
go to a list of people I just pipe the output to mail.
In vixie cron and most others, you can specify a user to get the mail, 
it generally looks something like:

[EMAIL PROTECTED]
man 5 crontab, it's enlightening.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-01-11 Thread Bill McGonigle
On Jan 11, 2005, at 5:24 PM, Ed Lawson wrote:
 I have found in the syslog that cron
ran the right commands at the right time.  However, no var/log/cron
Ah, you might want:
# Log cron stuff
cron.*  /var/log/cron
in your /etc/syslog.conf
-Bill
-
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
[EMAIL PROTECTED]   Cell: 603.252.2606
http://www.bfccomputing.com/Text: [EMAIL PROTECTED]
AIM: wpmcgonigleSkype: bill_mcgonigle
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-01-11 Thread Ed Lawson
Thanks for the great suggestions.  I have found in the syslog that cron
ran the right commands at the right time.  However, no var/log/cron and
no mail, but that is likely due to lack of output, etc.  I have changed
scripts as suggested and we shall see what shows up in the morning.

Ed Lawson
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-01-11 Thread Michael ODonnell


> On my Debian boxes, cron jobs send me an email if and
> only if they have any output.

IIRC, it's slightly more subtle than that.  I think the user
on whose behalf the script in question is running gets mail if
stdout/stderr haven't been redirected, regardless of whether
any output was actually generated on those channels...
 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-01-11 Thread Randy Edwards
 > What is the best way to receive verification or otherwise check on
 > whether or not the job ran and if it ran to completion properly?

   Debian's cron jobs should e-mail you the output of the job.  As per "man 
cron":

"cron then wakes up every minute, examining all stored crontabs,  checking  
each  command  to  see  if it should be run in the current minute. When 
executing commands, any output is  mailed  to  the  owner  of  the crontab 
(or to the user named in the MAILTO environment variable in the crontab, if 
such exists)."

 Regards,
 .
 Randy

-- 
"Fascism could better be called 'corporatism', for it is merely the merging of 
state power with corporate power." -- Benito Mussolini, the Italian dictator 
who "invented" fascism
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-01-11 Thread Tom Buskey
Sometime cron logs output, sometimes it emails it.  It depends on how
your unix system is setup.

If the job doesn't echo stuff to the screen, you won't get anything.

I write my scripts to write to a file I can check later.  I then
append that to a log file and/or email it to an email alias for the
sysadmin or myself (if it's a oneoff).  I usually put timestamps all
over things too.



On Tue, 11 Jan 2005 11:42:22 -0500, Larry Cook <[EMAIL PROTECTED]> wrote:
> > On my Debian boxes, cron jobs send me an email if and only if they have
> > any output.
> 
> Also on RedHat 8 and Solaris.  I would guess that is the standard behavior for
> all distros.
> 
> > You could try putting an "echo Starting job..." in
> > someplace to see if you get something from that.
> 
> If it's a script, I usually put "sh -x " in front to echo all the lines of the
> script.
> 
> > Also, I believe the
> > mails are sent to root; I have an entry in /etc/aliases which actually
> > sends it to my normal user account.
> 
> I think it is sent to the account that owns the crontab file, which would be
> the account you did the "crontab -e" from.  If I want email to go to a list of
> people I just pipe the output to mail.
> 
> Larry
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-01-11 Thread Larry Cook
On my Debian boxes, cron jobs send me an email if and only if they have
any output.  
Also on RedHat 8 and Solaris.  I would guess that is the standard behavior for 
all distros.

You could try putting an "echo Starting job..." in
someplace to see if you get something from that.  
If it's a script, I usually put "sh -x " in front to echo all the lines of the 
script.

Also, I believe the
mails are sent to root; I have an entry in /etc/aliases which actually
sends it to my normal user account.
I think it is sent to the account that owns the crontab file, which would be 
the account you did the "crontab -e" from.  If I want email to go to a list of 
people I just pipe the output to mail.

Larry
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-01-11 Thread Stephen Ryan
On Tue, 2005-01-11 at 11:16, Ed Lawson wrote:
> On Tue, 11 Jan 2005 10:44:07 -0500
> Bill McGonigle <[EMAIL PROTECTED]> wrote:
> 
> >
> > 
> > For 'otherwise check' there's /var/log/cron.
> > 
> 
> For whatever reason my Debian boxes do not have that file or directory.
> Maybe nothing is working.

On my Debian boxes, cron jobs send me an email if and only if they have
any output.  You could try putting an "echo Starting job..." in
someplace to see if you get something from that.  Also, I believe the
mails are sent to root; I have an entry in /etc/aliases which actually
sends it to my normal user account.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-01-11 Thread Ed Lawson
On Tue, 11 Jan 2005 10:44:07 -0500
Bill McGonigle <[EMAIL PROTECTED]> wrote:

>
> 
> For 'otherwise check' there's /var/log/cron.
> 

For whatever reason my Debian boxes do not have that file or directory.
Maybe nothing is working.

Ed Lawson
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: cron job verification

2005-01-11 Thread Bill McGonigle
On Jan 11, 2005, at 10:37 AM, Ed Lawson wrote:
What is the best way to receive verification or otherwise check on
whether or not the job ran and if it ran to completion properly?
For 'otherwise check' there's /var/log/cron.
What I'd love to see is a program that you can put patterns in for 
particular jobs' output indicating pass/fail/indeterminate which would 
alert the sysadmin iff the job doesn't complete successfully, log 
otherwise.  Some stats and maybe a baysian classifier would be nice.

Anybody have one of these?  I could shoehorn procmail to do it but it's 
not exactly the right tool for the job.

-Bill
-
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
[EMAIL PROTECTED]   Cell: 603.252.2606
http://www.bfccomputing.com/Text: [EMAIL PROTECTED]
AIM: wpmcgonigleSkype: bill_mcgonigle
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


cron job verification

2005-01-11 Thread Ed Lawson
I have several cron jobs that I have written to sync various
directories and to do backups.  I did this via crontab -e as root.
My question is how do I verify the operation of the these jobs. I
thought there would be mail sent to root or its alias upon completion,
but there is none.

What is the best way to receive verification or otherwise check on
whether or not the job ran and if it ran to completion properly? 

I suspect the answer to the question is absurdly obvious, but I'm
stupid.

Ed Lawson
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss