I've got a cronjob that executed a shell script
Inside my shell script i do a
module load tww/perl
but it gives me
module: command not found
what can i do? I have at least 10 modules I need to load
Well, I'm late but replacing
#!/bin/bash
by
#!/bin/bash -l
works for me.
It seems likely your script depends on an environment setting, such as the initial path to your modules, that cron doesn't know about. By default the cron environment is quite austere, or so it is on *nix systems I use.
Related
I have a bash script (clean.sh) that runs fine by hand but doesn't run when run from cron.
cd /usr/share/clean_addr/bin/
cleanme cleanme.ini
When the clean.sh script is by cron the cleanme exe is not found. I gave an absolute path to the cleanme exe but then its supporting library files were not found.
cd /usr/share/clean_addr/bin/
/usr/share/clean_addr/bin/cleanme cleanme.ini
The cron runs under the same user account as that in which the script ran manually. What do I need to set to get this to work.
Sincerely,
Stephen.
The answer is that the cleanme application required environment variables that were set on the user account, but were not known by cron because cron doesn't resolve those settings. Explicitly setting the environment variables for cleanme in the .sh resolved the issue
CLEANME_PATH=/usr/share/clean_addr/bin/
export CLEANME_PATH
It's jenkins installed as a package, which executes phing, but everything is executed with /bin/sh it seems. So bash_env is not an option I think. Can anybody help me with this?
You can change Shell executable under the Manage Jenkins configuration
I am sure this has to be out there somewhere, but after about a day of searching I am stuck. I am trying to use IZPack to do an installation on Linux and trying to call a shell script that sets some environment variables. However I don't know how to "source" the script instead of just running it. Running the script using:
<executable type="bin" stage="postinstall" targetfile="$INSTALL_PATH/myscript.sh" os="unix"/>
This only executes the script, it does not source it. So all exports of ENV variables are lost once the script completes.
How can I source my scripts from IZPack instead of just running them?
IMHO you simply cannot influence the shell environment your Java process of your IzPack installer is running in from that process itself.
Torsten is right. This is not an issue of IzPack, Java or anything else, this is just the way operating system process work with respect to environment variables ;-)
I'm attempting to load several modules for building a library on Linux but am told that the command 'module' doesn't exist. I've Googled around and discovered that the solution was to source a directory called "module" which I am unable to locate despite extensive searching.
I'm not quite sure what I should and any help would be appreciated (it might help to know that the makefile I'm working with uses csh while my default shell is bash). Thanks!
I tried to reproduce it and it turns out that for me sourcing
source /etc/profile.d/modules.sh
in th .sh script helps for bash and similar. For csh and tcsh, you have to add
source /etc/profile.d/modules.csh
to the script. Note, that this line must come first and then the
module load foo
line.
I got here as I was searching for ways to install multiple php versions in CentOS7 and https://blog.remirepo.net/post/2019/05/22/PHP-7.4-as-Software-Collection was one of the articles I tried to follow and encountered the same "module: command not found" issue.
Sourcing /etc/profile via command:
. /etc/profile
seems to make the "module load" work.
Credits to fadishei in https://forums.fedoraforum.org/showthread.php?262708-module-command-not-found
To make the version of php (e.g. php7.4) persist, append the following to file /etc/profile.d/custom.sh
source /etc/profile.d/modules.sh
module load php74
Reboot and run the php --version to cross-check that php 7.4 is the current version installed.
I think that you have to put this in your script to define the module command:
module () {
eval `/usr/bin/modulecmd bash $*`
}
This was working for me
#!/bin/bash -i // it will make this interactive
I have an escript file which runs fine from the command line, i.e.:
./escript_file
It is meant to be cron friendly and all paths are explicit but when I run it, it fails to compile saying that there are bad attributes.
The bad attributes in question are macro definitions:
-define(COOKIE, 'somecookie').
The Answer
Thanks to Geoff Ready's suggestion I investigated which version of Erlang was running by printing out init:script_id() which prints out a string like {"OPT APN 181 O1", "R13B"} and, sure enough the command line and cron versions were picking up different versions.
The script had an initial line:
#!/usr/bin/env escript
and the operating system was 'finding' Erlang for me. The different environment variables of cron meant that a different erlang was being picked up (Geoff's first answer, and one I kinda knew but couldn't see how it would affect things).
The solution is then to force the version with a starting line of:
#!/usr/local/lib/erlang/erts-5.7.3/bin/escript
Postscript
There was also a different Ubuntu apt-get install of an earlier version of Erlang (in a different location to the source install) and an errant 64-bit install...
The cron environment just kept falling back to older and more obscure installs, failing all the while :(
Perhaps cron is picking up a different version of erlang in the path. Erlang R12B documentation says that escript ignores preprocessor directives besides include_lib. Erlang R13B documentation says that the preprocessor is run on the file. That would definitely explain the difference in behavior.
If it is working fine from the command line, a likely cause is a difference in environment variables for your interactive shell versus when cron runs the script.
Changing #!/usr/bin/env escript to #!/usr/local/bin/escript at the top of the file will work if the Erlang versions are the same.