I am trying to automate an application restarts with Python which is currently implemented with shell scripts. Before running the restart commands, we need to source a .sh environment file which is done in the shell script with
. ./opt///**.sh. I am using paramiko and exec_command to run the restart command which throws the error that libraries are missing. So I have tried several ways to source this environment file in the python program but have not been successful.
Things I have tried:
stdin1,stdout1,stderr1 = ssh_client1.exec_command(". ./opt///**.sh")
stdin1,stdout1,stderr1 = ssh_client1.exec_command("source /opt///**.sh")
subprocess.call("/opt///**.sh", shell=True)
os.system(". /opt///**.sh")
I picked the below from stack overflow if I remember correctly
enter code herecommand = shlex.split("bash -c 'source /opt///**.sh'")
enter code hereproc = subprocess.Popen(command, stdout = subprocess.PIPE)
enter code herefor line in proc.stdout:
enter code here(key, _, value) = line.partition("=")
enter code hereos.environ[key] = value
enter code hereproc.communicate()
I still get the same error missing libraries which I am supposed to get when I do not source the environment file when I run the application restart commands using exec_command("/opt///start")
Any help is really appreciated.
Thanks.
#Martin Prikryl: Execute multiple commands in Paramiko so that commands are affected by their predecessors
I love you man!! I am writing a py script to remote ssh with paramiko that sources a local environment file before running application restart commands. I was breaking my head over this for over 2 weeks, until I read this post. It works like a charm. Thank you!!
Solution:
Each exec_command multiple times is executed in its own "shell". So the previous commands have no effect on an environment of the following commands.
Use && to combine the commands. In this way, the previous command, which in my case is the environment file, has an effect on the following command.
stdin3,stdout3,stderr3 = ssh_client1.exec_command(". /opt///env.sh && STOP")
Related
I changed the environmental variable LD_LIBRARY_PATH from the Ubuntu terminal (because I was receiving an error) and the changes were applied when I ran code (a Python code) from the terminal. But when I ran the same script from the Visual Studio Code, the error remains. How to update the environmental variable so that Visual Studio Code sees it, as well?
Environment variables are passed from parent process to child process; they are not (say) global to the system or the user. If you change a variable in one shell, the change is only seen in that shell and any processes started from that shell. So the simplest solution is to change the variable and then start VSCode from that same shell:
$ export LD_LIBRARY_PATH=/some/useful/path
$ code
If you want to keep using that shell for other things, run it in the background:
$ code >/dev/null 2>&1 &
The redirection to /dev/null is needed because otherwise VSCode prints logging information periodically, and that output will be mixed with whatever else you're doing.
If you want to set the variable permanently, see the question How do I set a user environment variable? (permanently, not session). After following those instructions, you'll need to start a new shell (and possibly even logout and login) first so the settings take effect. Then launch VSCode from the new shell.
I am having trouble launching an executable that I have created from a shell script. I would like to automate testing by running the program many times with different command line options to verify it is working.
When I type echo $SHELL, /bin/sh is displayed.
The following is my shell script:
#!/bin/sh
clear
echo "Running first test."
./myProgram
exit 0
When I run the script (sh myScript.sh), with myProgram in the same directory, I see the following output:
Running first test.
: not foundsh: line 4:
When executing the program ./myProgram, it runs as expected with no command line options.
I have also tried:
myProgram
./myProgram &
myProgram &
based on answers to somewhat similar questions, but they all result in the above error message.
Your newlines are goofed. Use dos2unix to fix.
why don't you try using the full path?
e.g., if myProgram is in /home/user1/bin, you can try /home/user1/bin/myProgram instead of ./myProgram. This should work.
You can also add the path to path variable, $PATH and directly call myProgram from anywhere.
Run "export PATH=$PATH:/home/user1/bin" on your terminal without the quotes. Note that this affects only your current termial session. If you want to permanently add the path, update your .bashrc file in your home directory with the following line:
I'm developing a Nagios plugin in Perl (no Nagios::Plugin, just plain Perl). The error condition I'm checking for normally comes from a command output, called inside the plugin. However, it would be very inconvenient to create the error condition, so I'm looking for a way to feed test output to the plugin to see if it works correctly.
The easiest way I found at the moment would be with a command line option to optionally read input from a file instead of calling the command.
if($opt_f) {
open(FILE, $opt_f);
#output = <FILE>;
close FILE;
}
else {
#output = `my_command`;
}
Are there other, better ways to do this?
Build a command line switch into your plugin, and if you set -t on the command line, you use your test command at /path/to/test/command, else you run the 'production' command at /path/to/production/command
The default action is production, only test it the switch indicating test mode is present.
Or you could have a test version of the command that returns various status for you to test (via a command line argument perhaps).
You put the test version of mycommnd in some test directory (/my/nagois/tests/bin).
Then you manipulate the PATH environment variable on the command line that runs the test.
$ env PATH=/my/nagois/tests/bin:$PATH nagios_pugin.pl
The change to $PATH will only last for as long as that one command executes. The change is localized to the subshell that is spawned to run the plugin.
The backticks used to execute the command will cause the shell to use the PATH to locate the command, and that will the the test version of the command, which lives in the directory that is now the first one on the search path.
let me know if I wasn't clear.
New answer for new method.
I have a perl script (which syncs delicious to wp) which:
runs via the shell but
does not run via cron (and i dont get an error)
The only thing I can think of is that it read the config file wrongly but... it is defined via the full path (i think).
I read my config file as:
my $config = Config::Simple->import_from('/home/12345/data/scripts/delicious/wpds.ini',
\my %config);
(I am hosted on mediatemple)
Does anybody have a clue?
update 1: HERE is the complete code: http://plugins.svn.wordpress.org/wordpress-23-compatible-wordpress-delicious-daily-synchronization-script/trunk/ (but I have added the path as above to the configuration file location as difference)
update 2: crossposted on https://forums.mediatemple.net/viewtopic.php?pid=31563#p31563
update 3: the full path did the trick, solved
The difference between a cron job and a job run from the shell is 'environment'. The primary difference is that your profile and the like are not run for a cron job, so any environment variables you have set in your normal shell environment are not set the same in the cron environment - no extensions to PATH, no environment variables identifying where Delicious and/or WP are hosted, etc.
Suggestion: create a cron job that simply reports the environment to a known file:
env > /home/27632/tmp/env.27632
Then see what is set in your own shell environment in comparison. Chances are, that will reveal the trouble.
Failing that, other environmental differences are that a cron job has no terminal, and has /dev/null for input and output - so interactive stuff does not work well.
it seems the problem is not in running perl, but locating the Config library
you should try:
perl -e "print #INC"
and run a similar perl script in cron, and read the output
it possible that they differ
I suggest looking at my answer to How to simulate the environment cron executes a script with?
This is an similar Jonathan's answer but goes a bit further.
Based on your crontab, and depending on your installation, the problem might be the "perl". As others note the environment, particularly the $PATH variable, is different for cron. perl may not be in the path so you need to put the full path to perl in the cron command.
You can determine the path with the command $ type perl
I run into the same problem ...
Perl script works but not via CRON => error: "perl: command not found"
... after an update from Plesk 12.0 to Plesk 12.5. But the existing answers were not very helpful for me.
It took some time, but than I found this thread in the Odin forum which helps me: https://talk.plesk.com/threads/scheduled-tasks-always-fail.331821/
They suggest the following:
/usr/local/psa/bin/server_pref -u -crontab-secure-shell ""
That deletes in the /var/spool/cron/crontabs files the line:
SHELL="/opt/psa/bin/chrootsh"
After that, my cron jobs run with out any error.
(Ubuntu 14.04 with Plesk 12.5)
If the perl script runs fine manually, but not from crontab, then
there is some environment path needed by the some package that is not
getting through `cron`. Run your command as follows:
suppose your cron entry like:
* 13 * * * /usr/bin/perl /home/username/public_html/cron.pl >/dev/null 2>&1
env - /home/username/public_html/cron.pl
The output will show you the missing package. export that package path in
$PATH variables
Permission denied (publickey,keyboard-interactive) got this error while i am trying to cvs checkout from perl.
what is issue and how to reslove this ?
Code :
system ( "CSVROOT:--- CVSRSH:--- cvs co a ");
# i have proper value in cvs root and cvs rsh .
its running alone and using ssh key
Steps to diagnose the error:
Are you using an SSH key?
Does that key have a passphrase?
Does it work when you run it by hand?
Is the script running as the same user as when you run it by hand?
Is the script running under the same environment as when you run it by hand? (e.g. cron jobs do not run under the same environment)
If you think all of the answers are yes, then most likely the last answer is really no. If the script is running from a scheduler like cron it most likely does not run with the same environment as when you run it by hand. The way I normally solve this is to use a shell script between the scheduler and the Perl script:
#!/bin/bash
source /home/USERNAME/.profile
#set any other environment variables it needs like
export CSVROOT=:pserver:USERNAME#HOST:/path/to/repo
export CVSRSH=ssh
/path/to/perl/script/script.pl
Follow-up investigations after Chas.'s questions:
Does that command normally run under /bin/sh or some other shell?
To test, execute /bin/sh command to start Bourne shell and try the command by hand again.
I'm not familiar with "CVSROOT:---" notation - is that meant to set CVSROOT environmental variable? In Bourne shell it's usually done using "=", never saw ":" used.
Does the command, when run by hand, expect some input from you? I never saw cvs co to do so, but I don't use it with ssh.
Try to add a redirect to the end of the command and look what's in the file after running:
system ( "CSVROOT:--- CVSRSH:--- cvs co a > /tmp/log_cmd 2>&1");