topic Re: understanding command in Operating System - HP-UX

understanding command

Joy Conner — Fri, 29 Oct 2010 15:24:52 GMT

I have the following command set up in a cron:

15 2 * * 5 /usr/sam/lbin/br_backup LTO FULL Y /dev/rmt/0m /var/sam/graphRCAa16294 root Y 1 N > /var/sam/SAM_br_msgs 2>&1 #sambackup

I understand crons and I understand this executes our backup and I get an email from the system. I need help understanding this part...

> /var/sam/SAM_br_msgs 2>&1 #sambackup

I cannot find any files on my system named "SAM_br_msgs" and sambackup. I do not understand what 2>&1 means.

So if anyone is willing to shed some light on this, I surely will be appreciative.

Re: understanding command

Pete Randall — Fri, 29 Oct 2010 15:39:31 GMT

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=989479

Pete

Re: understanding command

Patrick Wallek — Fri, 29 Oct 2010 15:45:27 GMT

There should be a file in /var/sam called SAM_br_msgs. All messages from the backup should get written there.

The '#sambackup' is just a comment. No need to worry about that.

Re: understanding command

Matti_Kurkela — Fri, 29 Oct 2010 16:19:59 GMT

The part "> /var/sam/SAM_br_msgs 2>&1" is about input/output redirection, a basic feature of Unix.

Each command you run will normally have three standard file descriptors, connected to standard input/output streams. Usually these streams are connected to your terminal, but you have the option of redirecting them to something else.

The first of these standard streams is the standard input stream, or stdin for short. It is associated with file descriptor 0. Its usual role is passing the data you type from the terminal to the program.

The second standard stream is the standard output stream, or stdout. It is associated with file descriptor 1. Its usual role is passing the output of the program to the terminal.

The third standard stream is the standard error output, or stderr. It is associated with file descriptor 2. It is distinct from the standard output, so that you can still see any error messages on your terminal if you redirect the regular output stream somewhere else. Or you can redirect the regular output to one place and errors to another.

The standard input and output are redirected using the redirection operators <, > and >>. The standard error output can be redirected using "2>" or "2>>".

You can also refer to the standard input and output streams using the full form of the redirection operators, like 0< or 1>, but the short forms are overwhelmingly more common with these streams.

"> /var/sam/SAM_br_msgs" (with or without the space) means "redirect the standard output of this command to file /var/sam/SAM_br_msgs. Any existing data in the file will be overwritten when the command is executed, even if it does not produce any output. If the file does not exist, it will be created.

"2>&1" means "redirect the standard error output to file descriptor 1", i.e. "send the program's error messages to the same place as the standard output goes". As the standard output was redirected to file /var/sam/SAM_br_msgs, any error messages produced by the br_backup command will end up there too.

Since "/var/sam/SAM_br_msgs" begins with the "/" character, this is a fully-qualified path name: it unambiguously identifies where the file should be. If the file does not exist, perhaps some other cron job deletes it?

Or perhaps there is something wrong with the command line, and it cannot be executed? The cron daemon will normally send email to the owner of the job only if the job produces any output that is not redirected elsewhere, or if the command returns with an error code. As all the output of this command (including error messages) should go to /var/sam/SAM_br_msgs, there should be no output going to the mail message at all.

The part "#sambackup" is just a comment: anything after the # character will have no effect, and can be used to describe the purpose of the command line. In this case, it probably indicates this command line was produced using SAM.

MK

Re: understanding command

TwoProc — Fri, 29 Oct 2010 18:05:10 GMT

I think your problem may be how complicated your command is, and then running a complex command in cron.
I find it much more reliable to make a cron command file somewhere, and run that.

Your file(my_backup, for example) would contain:

/usr/sam/lbin/br_backup LTO FULL Y /dev/rmt/0m /var/sam/graphRCAa16294 root Y 1 N > /var/sam/SAM_br_msgs 2>&1

And your cron command would be:

15 2 * * 5 /home/admin/croncmds/my_backup >/dev/null 2>&1

Of course, you can move that "my_backup" command anywhere you'd like, you get the picture...

I just find that my stuff runs more reliably and happily from cron if I make a command file out of it. Much fewer problems that way.

Re: understanding command

Joy Conner — Fri, 29 Oct 2010 19:01:15 GMT

There is no file "SAM_br_msgs" and I don't see a cron cleaning it up. I do get the content in an email message.

Thanks for shedding light on this. My sysadmin guy is not here any more and I'm it for now.

- Joy

Re: understanding command

Dennis Handly — Sat, 30 Oct 2010 00:05:50 GMT

>I do get the content in an email message.

What does it show?
Does /var/sam/ exist?

Re: understanding command

eric lipede_1 — Sat, 30 Oct 2010 02:34:06 GMT

Joy
Have you tried running the job on the command line to see if the file is created ?
This will eliminate "cron" from the equation. If it still isnt there then the problem may well be in your br_backup (or your options). I take it its a SAP / Oracle backup ? or is it just named "br*" ?.
My suggestions would be:

1. Run full command as is on the command line;
2. if no "joy", then the problem would be in the br_backup or the options used;
3. try running the command without the re-direction part ie "/usr/sam/lbin/br_backup LTO FULL Y /dev/rmt/0m /var/sam/graphRCAa16294 root Y 1 N" - if theres no output, then theres definitely an issue with the backup or lack thereof.
4. Check the permissions of /var/sam and make sure its writeable

Re: understanding command

Joy Conner — Mon, 01 Nov 2010 11:02:47 GMT

I do have a log in /var/sam/log named br_log. Here is sample content

Full backup started on roa6 : Fri Oct 29 05:00:00 EDT 2010 (Scheduled Backup)
{ fbackup -0 -u -g /var/sam/graphFGAa04508 -I /var/sam/log/br_index.full -c /etc/sam/br/fbackup_config -d /var/adm/fbackupfiles/dates -f /dev/rmt/1m } 2>&1
Full backup completed successfully on roa6 : Fri Oct 29 05:52:48 EDT 2010 .
Exit code = 0

Re: understanding command

Dennis Handly — Mon, 01 Nov 2010 11:12:23 GMT

>I do have a log in /var/sam/log named br_log.

Perhaps br_backup automatically sends its log info to br_log. If br_backup is a script, you can search for br_log.

Re: understanding command

Joy Conner — Mon, 01 Nov 2010 13:18:58 GMT

I found the script br_backup.

Re: understanding command

Patrick Wallek — Mon, 01 Nov 2010 13:40:09 GMT

OK. And.......

Re: understanding command

Viktor Balogh — Mon, 01 Nov 2010 14:17:07 GMT

>I found the script br_backup.

# file br_backup

if it is really a script; you can see what it does:

# less br_backup

Re: understanding command

Joy Conner — Mon, 01 Nov 2010 14:52:42 GMT

I can tell that Patrick must be inclined to teach.

I see in the script that when the backup results are mailed, the stdout and the stderr are output to SAM_br_msgs.

Thanks for the push. :-)

Joy