Can I define PROJECT_HOME = /home/a/b/c
and use it later with something like {{PROJECT_HOME}} inside supervisord conf?
If you have an environment variable named VARIABLE. Then inside the supervisord.conf you should use %(ENV_VARIABLE)s
Related
is it possible to set sort of a project-variable in rundeck?
I am organizing jobs in projects, but the jobs are mostly the same and use the same values over and over again. If I could set variables per project, I could just copy jobs from project to project without having to adapt the same parameters over and over again...
like... path=/path/to/project
and use the variable path in jobs
Thanks, regards
Jochen
You can define a global variable for that. You can define it on framework.properties file like framework.globals.myvar=myvalue or at project level (project.properties config) like project.globals.myvar=myvalue, to access it just use ${globals.myvar} for steps, #globals.myvar# for inline-scripts or $RD_GLOBALS_MYVAR for scripts.
UPDATE:
In Rundeck 3.1/3.2/3.3/4.X the "project.properties" isn't a "file", is a config reachable/editable following this.
I have a variable set in a bbclass file like:
#some-class.bbclass
PROC ??= ""
In a recipe inheriting the class, I have a bash function where I modify that variable and immediately read its value. But, the value never gets updated.
#some-bb-file.bb
inherit some-class.bbclass
some_configure() {
PROC=$(grep -r "Processor.*${cpu_id}" ... something)
bbnote "PROC is ${PROC}"
}
I always get "PROC is " in the logs. I have tried printing the output of "(grep -r "Processor.*${cpu_id}" ... something)" and it returns a valid string. Can someone please tell me what I am missing?
Usage of bitbake and shell variables in your code snippet is mixed. Your bbnote line should omit the curly braces to access the shell variable, i.e.:
bbnote "PROC is $PROC"
Explanation: The bitbake and local shell variables are different. If you are in the shell function, then ${PROC} is the variable defined in some-class.bbclass. That variable isn't redefined when you do PROC="foo". If you use $PROC, the shell variable defined by PROC="foo" is used.
And your question in the title - I'm not sure if it is possible to update datastore variable from shell. You can get and set datastore variables in Python functions (using d.getVar and d.setVar).
Datastore variables can be read from Shell using :
${#d.getVar('PROC')}
In case you have to use others operations, then switch to Python
I guess you missed backticks
PROC=`grep -r "Processor.*${cpu_id}" ... something`
bbnote "PROC is ${PROC}"
I'm using this article as a source to get me half way there, but I cannot figure out how to run supervisor with a custom config file path.
When I want to run supervisor manually, I just do:
supervisord -c /home/test/_app/supervisord.conf
When I implemented the auto start up script, it runs the default supervisor config file which is located in /etc/ directory. I don't want to use that one because it separates it from the core project folder and makes it hard to maintain and keep track of.
Try this:
In /etc/rc.d/init.d/supervisord, add prog_opts variable like this:
prog_opts=" -c /home/test/_app/supervisord.conf"
prog_bin="${exec_prefix}/bin/supervisord"
Then in start() function, change the call to:
daemon $prog_bin --pidfile $PIDFILE -- $prog_opts
I was able to fix this issue by simply deleting the default supervisord.conf file and then making a sym link with that default location and my custom conf file path.
I am trying to run grafana but i need to specify the port using an environment variable. Currently, in the custom.ini i have
# The http port to use
http_port = 9082
how do i assign an environment variable to http_port ? It would be best if i could do it from the command line but the only command line options available are
Usage of bin\grafana-server.exe:
-config string
path to config file
-homepath string
path to grafana install/home path, defaults to working directory
-pidfile string
path to pid file
-v prints current version and exits
is there any way to assign an environment variable to the http_port?
I'm not a Windows user but I guess you can write a script (bat?) to first generate the custom.ini file filling http_port with an environment variable, then run grafana-server.exe pointing to the generated config file.
I'm not a perl expert and I don't quite get how all of perl's scoping rules work.
I'm setting an $ENV{'whatever'} environment variable, then I'm calling a function in another source .pl file and trying to read that ENV entry, and I'm getting nothing back. Docs say everywhere that ENV persists for the current process and any forked children, but is access to the %ENV variable available in other source files?
The source file was included via a 'require' command. Is that the right way to do it, or is there something static (first time in) about how variables are made available when a source file is required?
%ENV is a global, so it is accessible from everywhere in every source file loaded into a process.
%ENV is inherited when a new process is created with a fork but the new process gets its own copy so any changes made in one will not be visible in the other.
If you're loading the other source file with do or require or use then it's being loaded into the same process and it will see the same %ENV.
However if you're loading the new script with system or exec then the new script is loading in a new process and it will get its own copy of %ENV.
From perldoc perlvar:
%ENV
The hash %ENV contains your current environment. Setting a value in
ENV changes the environment for any child processes you subsequently
fork() off.
require-ing a .pl file is not the same as forking a command.
It would be simpler to just set the necessary environmental variables through a Bash wrapper:
$ cat wrapper.sh
#!/bin/bash
export whatever="/usr/bin/some_dir/"; # Set to env
perl script.pl; # Invoke the script
$ cat script.pl
#!/usr/bin/perl
print $ENV{whatever}; # wrapper.sh : "/usr/bin/some_dir/"
# script.pl : ""