Running a script on remote server kills my login session

Hi there,

I'm trying to run a script remotely on a server in a particular directory named after hostname which already exists, my login session gets killed as soon as I run the below command. Not sure what is wrong, is there a better way to do it ?

Note: I can also use nohup command to run this command in background but prefer to use 'at' job.

ssh -l username@hostname "echo "cd /tmp\`hostname\` && exec ./test.sh" | at now"

cat test.sh
#!/bin/ksh
DIR=`pwd`
LOGS=$DIR/LOG
mkdir -p $LOGS

Also tried enclosing the command with ( ) but it gives syntax error,

ssh -l username@hostname "echo "( cd /tmp\`hostname\` && exec ./test.sh )" | at now"

Why are you using exec?
Or more you tell me what happens at the end of execution...

Check those double quotes, you have to escape the inner ones. As it stands now, it executes parts of the command locally.

Juha

I'm trying to execute the script and it just kills my session at the end of execution.

Well, I'm afraid that without further detailed info we won't get anywhere. WE CANNOT replicate your setup. YOU NEED to post what happens, and when. The more info you post, the higher the probabilty of a solution.
Which part is running where? Does the at command start? Does it crash? Any error message (and don't say "yes!")? Log entries?

if you look at the red-colored characters below, you will see that you have 2 groupings of "command arguments" with the '&&' operator in between.

ssh -l username@hostname "echo "( cd /tmp\`hostname\` && exec ./test.sh )" | at now"

since the exec command immediately follows &&, your malformed command line is basically saying run the ssh command and then run exec. correct code should be ...

ssh -l username@$hostname "echo '(cd /tmp\`hostname\` && exec ./test.sh)' | at now"

or something closer. verify on your platform. either way, your error is with your command groupings done by your double quotes.

1 Like

I had to refrain from using 'exec' command as it abruptly ends my login session as soon as I run the command without giving any errors and also got rid of '&&'.
Btw..this is ksh on AIX OS.

Below is the code that works for me and I'll start using it unless anyone sees an issue with it or comes up with anything better.

ssh -l username@$hostname "echo '(cd /tmp/\`hostname\`;./test.sh)' | at now"

Thanks to all for your quick responses esp. 'Just Ice' for pointing to the quoting issue.

The problem you have now is that there is no error check that the change of directory worked.

Would running ./test.sh in the home directory cause a problem?

I would avoid the exec, there is just no need and perhaps a script called test.sh is not a great idea given that test is a reserved word.

Why do you feel you need to run your code with at anyway? What's wrong with this?:-

ssh -l username@hostname 'cd /tmp/$(hostname) && nohup ./test.sh &'

Note the single quotes so that $(hostname) is executed on the target. You can choose to capture the output to a file, leave it to default to nohup.out or redirect it to /dev/null as you please.

Robin

1 Like

Thanks for suggesting to use && which does the error check and I'd change the script name once it is complete as I need to add some more functionality.

The reason I prefer using at over nohup is sometimes ssh tends to not exit after running the remote job if the script that is running receives some input/output values and I do have these values that are called within a script.

All the standard output and errors from a nohuped job will be written to file nohup.out unless you tell it otherwise and by putting the remote script in the background, your ssh will then end. I'm not sure why running with at is more beneficial except that any unhandled output to 'screen' should end up as an email to the user account running the job.

Can you try it and post any unwanted results? If you think your code may pause for input, then you are no worse off.

Robin

I ran using nohup and it works the same way as at except that nohup sends the output to screen as well and I'd like set it up to receive an email only option to the user running the job rather than outputting to the screen.

One more thing I was wondering is how to validate and notify the user if the remote script has actually started running ?

Thanks!

I'd like to pass 1 argument to the below code from a script called mail.sh that runs this code on remote server, any idea how to do it, I tried double quotes but it runs on the local server and also the back slash doesn't work either ?

cat mail.sh
#!/bin/ksh
if [ "$SERVER" = "" ]
then
   echo "............................"
   echo "Enter server name: \c"
   read SERVER
   echo "Enter MAILID: \c"
   read MAILID
   ssh -l username@$SERVER 'cd /tmp/$(hostname) && nohup ./test.sh \${MAILID}&'
else
  echo "Check your mail for an update"
fi

If you want $hostname to be expanded on $server and $MAILID to be expanded locally, try changing:

   ssh -l username@$SERVER 'cd /tmp/$(hostname) && nohup ./test.sh \${MAILID}&'

to:

   ssh -l username@$SERVER 'cd /tmp/$(hostname) && nohup ./test.sh'" ${MAILID}&"

Would this do the same?:-

ssh -l $username@$SERVER "cd /tmp/\$(hostname) && nohup ./test.sh ${MAILID}&"

I think that this should pass the literal text $(hostname) across to be interpreted by the remote system, but the value of S{MAILID}

Some people may prefer this style but I'm prepared to be corrected it is wrong.

It does strike me though that you will get no output/mail if the change of directory fails. Would this be a problem to you? You may be better to both set the directory and test for it within your script and then alert on failure from within there, if appropriate.

Robin

I tried using the nohup option and for some reason it exits the script abruptly on the remote server but it works just fine with 'at' job and I'm also able to pass an argument on remote server with no issues. I'm also doing directory checking on remote server, if present the script will continue otherwise exits.

ssh -l $username@$SERVER "echo '(cd /tmp/\$(hostname) && ./test.sh ${MAIL_TO})' | at now"

Thanks to all for your valuable suggestions.