How do I specify a working directory for mnesia without resorting to passing the "dir" parameter on the command-line?
In other words, can I specify a "working directory" for mnesia just before calling `mnesia:start()' ?
application:set_env(mnesia, dir, Dir).
Besides the method call mentioned in other responses here you can also specify this in a system configuration file or .app file specified with the -config parameter. See http://erlang.org/doc/design_principles/applications.html#id2270704 for more information. This allows you keep the configuration seperate from the code and avoid a lot of command line flags.
Related
My goal is to put my telegraf config into source control. To do so, I have a repo in my user's home directory with the appropriate config file which has already been tested and proven working.
I have added the path to the new config file in the "default" environment variables file:
/etc/default/telegraf
like this:
TELEGRAF_CONFIG_PATH="/home/ubuntu/some_repo/telegraf.conf"
... as well as other required variables such as passwords.
However, when I attempt to run
telegraf --test
It says No config file specified, and could not find one in $TELEGRAF_CONFIG_PATH etc.
Further, if I force it by
telegraf --test --config /home/ubuntu/some_repo/telegraf.conf
Then the process fails because it is missing the other required variables.
Questions:
What am I doing wrong?
Is there not also a way of specifying a config directory too (I would like to break my file down into separate input files)?
Perhaps as an alternative to all of this... is there not a way of specifying additional configuration files to be included from within the default /etc/telegraf/telegraf.conf file? (I've been unable to find any mention of this in documentation).
What am I doing wrong?
See what user:group owns /etc/default/telegraf. This file is better used when running telegraf as a service via systemd. Additionally, if you run env do you see the TELEGRAF_CONFIG_PATH variable? What about your other variables? If not, then you probably need to source the file first.
Is there not also a way of specifying a config directory too (I would like to break my file down into separate input files)?
Yes! Take a look at all the options of telegraf with telegraf --help and you will find:
--config-directory <directory> directory containing additional *.conf files
Perhaps as an alternative to all of this... is there not a way of specifying additional configuration files to be included from within the default /etc/telegraf/telegraf.conf file? (I've been unable to find any mention of this in documentation).
That is not the method I would suggest going down. Check out the config directory option above I mentioned.
Ok, after a LOT of trial and error, I figured everything out. For those facing similar issues, here is your shortcut to the answer:
Firstly, remember that when adding variables to the /etc/default/telegraf file, it must effectively be reloaded. So for example using ubuntu systemctl, that requires a restart.
You can verify that the variables have been loaded successfully using this:
$ sudo strings /proc/<pid>/environ
where <pid> is the "Main PID" from the telegraf status output
Secondly, when testing (eg telegraf --test) then (this is the part that is not necessarily intuitive and isn't documented) you will have to ALSO load the same environmental variables into the current user (eg: SET var=value) such that running
$ env
shows the same results as the previous command.
Hint: This is a good method for loading the current env file directly rather than doing it manually.
According to How does AOSP 9.0 build system link the executable? and What does # mean in this clang command in AOSP build log? , when linking a module, AOSP seems to produce a .rsp file that contains all the obj files that the module need,and pass the file name as a parameter to the link command, for example:
prebuilts/clang/host/linux-x86/clang-4691093/bin/clang++ /OpenSource/Build/Android/9.0.0_r30/soong/.intermediates/bionic/libc/crtbegin_so/android_x86_64_core/crtbegin_so.o #/OpenSource/Build/Android/9.0.0_r30/soong/.intermediates/frameworks/base/libs/hwui/libhwui/android_x86_64_core_shared/libhwui.so.rsp ......
But the .rsp files seems to be removed after build.
The question is, how are these file generated and how to get these files? This may require to learn and modify the build scripts which is out of reach for me.
There maybe the answer for you, read the ninja build manual , in that manual .rsp file mentioned.
https://ninja-build.org/manual.html
the following is info that I copy out.
rspfile, rspfile_content
if present (both), Ninja will use a response file for the given command, i.e. write the selected string (rspfile_content) to the given file (rspfile) before calling the command and delete the file after successful execution of the command.
This is particularly useful on Windows OS, where the maximal length of a command line is limited and response files must be used instead.
I have a C project and I would like to run QAC tool v7.0 from command line. I tried the following option,
C:\qac.exe -via <project_name.prj>
However, when I run the above command. I get an error saying the "VersionTag" is not found. The "VersionTag" string is the first line in the .prj file. I am not sure this is the right way to run this tool. Any help appreciated.
The qac -help is not giving valuable information either. The tool version is pretty old and the company 'Programming Research' behind this tool also has been renamed? to Perforce. They do not have any information about command line invocation either from the existing documentation or webpage.
The QAC utility is the "engine" part of the QAC package, corresponding to a compiler.
It won't be happy being run on command line without a number of environment variables:
QACBIN must point to the bin directory of the QAC package installation;
QACHELPFILES must point to the location of message help files;
QACOUTPUT points to the location where output files will be generated (binary .err file for each source file and textual .met file containing semantic and metric information.
The -via parameter to the command line should point at a text file containing other parameters used by the utility.
The .prj file is a package-level file defining the location of C source files being analysed plus their configuration settings files, among other things. It definitely should not be passed directly as a parameter to the QAC utility.
This should get you started, and other questions need to be more specific.
Is there ways to specify path to schema in cowboy app? Maybe it's possible to set in my_app.app.src or any config file?
The path to the mnesia directory has to be provided to erlang VM before mnesia application is started through application configuration parameters. In Mnesia tutorial, this is done with the -Application par val VM arguments syntax.
What you call a cowboy application is probably an Erlang OTP release (built by relx as per cowboy tutorial). The solutions, quickly described in Cowboy issue #595, are as follows.
The choice between solutions really depends on style as well as some constraints. Any sufficiently complex release would use a configuration file, so it would be a good choice. vm.args seems easier to deal with. Eventually, you might need to alter the start script (for example to run several nodes from a single deployment), and include some logic to define the mnesia directory.
Provide relx with a configuration file (sys_config option)
To do so, add the following term to relx.config as documented.
{sys_config, "./config/sys.config"}.
sys.config actually is a standard Erlang configuration file, also documented. Specifying mnesia dir is done by adding a section for mnesia application. If no other configuration is required, the file would be:
[{mnesia, [{dir, "/path/to/dir"}]}].
Get relx to pass arguments to the vm (vm_args option)
The vm.args file is actually passed to the VM through -args_file option. This is a simple text file with arguments.
You would add the following term to relx.config as documented.
{vm_args, "./config/vm.args"}.
And put the following content in the vm.args file:
-mnesia dir foo
Write your own start script
relx actually creates a start script, which passes -config sys.config and args_file vm.args to the VM as required. You could modify this script or roll your own to actually pass the -mnesia dir argument to the VM.
in case of vm.args, planit text -mnesia dir foo is invalid, please use format:
-mnesia {dir,foo}
I'm using org.apache.tools.ant.listener.Log4jListener to manage logging with my ant script. The ant script is highly configurable and designed to be run different ways with different parameters and therefore I need to be able to log to files specified at runtime. I have a log4j.properties which specifies a log file to be build.log, and despite my attempts to launch ant redefining properties defined in log4j.properties have been unsuccessful.
The build ignores them and continues to write to build.log. I haven't found much support regarding writing to custom files unless it's in Java with their Logger class.
Perhaps I'm thinking this through wrong. log4j.properties isn't treated in the same way as a property file in an ant script (hence overrideable from the command line)? Is there a way I can do this intelligently without writing a custom task or something?
You setup your log4j.properties file using a system property that you can define dynamically on the command line. The property below is "${logfile.name}". An example log4j configuration would be like this:
# logfile is set to be a RollingFileAppender
log4j.appender.logfile=org.apache.log4j.RollingFileAppender
log4j.appender.logfile.File=${logfile.name}
log4j.appender.logfile.MaxFileSize=10MB
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=[%-5p]%d{yyyyMMdd#HH\:mm\:ss,SSS}\:%c - %m%n
The command line option to pass a property, when calling "ant", is "-Dlogfile.name={runtime path/filename of log file}". Replace {runtime path/filename of log file} with your file name. When ant is run this value is set as a system property. That system property is then substituted into the log4j.properties at runtime.
http://ant.apache.org/manual/running.html