In sysvinit I would have an initscript, populate-volatiles.sh, that reads a volatiles file and creates the volatiles. What performs that function in systemd? Is there a systemd unit that does this? What is it and how do I configure it?
The unit I was looking for is systemd-tmpfiles. It creates volatiles/tmpfiles. Helpful docs here:
https://www.systutorials.com/docs/linux/man/8-systemd-tmpfiles/
Related
I am using test container with Janusgraph, but I need to use ConfiguredGraphFactory in my test. How to enable it in test container? This is how I am starting the test container:
GenericContainer<JanusGraph> janus = new JanusGraph()
.withNetwork(network)
.withExposedPorts(JANUS_PORT)
.waitingFor(Wait.forListeningPort())
.withStartupTimeout(Duration.ofMinutes(5))
.withEnv("janusgraph.storage.backend", "cql")
.withEnv("janusgraph.storage.hostname", storageName)
.withEnv("janusgraph.index.search.backend", "elasticsearch")
.withEnv("janusgraph.index.search.hostname", indexName)
.withEnv("janusgraph.schema.default", "tp3");
I was trying to add .withEnv("janusgraph.graph.graphname"."org.janusgraph.core.ConfiguredGraphFactory") but it doesn't work (image name: janusgraph/janusgraph:0.5.3).
The example yaml and properties files for trying ConfiguredGraphFactory can be found at:
conf/gremlin-server/gremlin-server-configuration.yaml
conf/janusgraph-cql-configurationgraph.properties
It is described in the janusgraph-docker project that you can define gremlin.* and janusgraph.* environment variables in your Dockerfile to override the default configs. Your approach with GenericContainer.withEnv() should be fine too.
From looking at this JanusGraph PR, I think this approach should work:
.withEnv("gremlin.graph"."org.janusgraph.core.ConfiguredGraphFactory")
However, I have no experience with JanusGraph and I think this is not a Testcontainers-specific question. This means you can conceptually configure it for Testcontainers the same way to would configure it for a Docker container with the Docker CLI.
I have an autotools project which successfully builds and tests an app (https://github.com/goglecm/AutoBrightnessCam). The app is installed in the bin directory (preceded by any prefix the user specifies). That's pretty straightforward. I now need to make a systemd service to start it at boot time. I've created the service file and ran it manually and it works fine.
The last bit is to tell configure.ac and Makefile.am to patch a *.service.in file with the correct path for the app (just like config.h is created from config.h.in).
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
Also, how do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
Is there perhaps a better way of starting this app at boot time without systemd?
How do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
According to Systemd's daemon man page:
<BEGINQUOTE>
Installing systemd Service Files
At the build installation time (e.g. make install during package build), packages are recommended to install their systemd unit files in the directory returned by pkg-config systemd --variable=systemdsystemunitdir (for system services) or pkg-config systemd --variable=systemduserunitdir (for user services). This will make the services available in the system on explicit request but not activate them automatically during boot. Optionally, during package installation (e.g. rpm -i by the administrator), symlinks should be created in the systemd configuration directories via the enable command of the systemctl(1) tool to activate them automatically on boot.
Packages using autoconf(1) are recommended to use a configure script excerpt like the following to determine the unit installation path during source configuration:
PKG_PROG_PKG_CONFIG
AC_ARG_WITH([systemdsystemunitdir],
[AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],,
[with_systemdsystemunitdir=auto])
AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [
def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)
AS_IF([test "x$def_systemdsystemunitdir" = "x"],
[AS_IF([test "x$with_systemdsystemunitdir" = "xyes"],
[AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])])
with_systemdsystemunitdir=no],
[with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
AS_IF([test "x$with_systemdsystemunitdir" != "xno"],
[AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])
This snippet allows automatic installation of the unit files on systemd machines, and optionally allows their installation even on machines lacking systemd. (Modification of this snippet for the user unit directory is left as an exercise for the reader.)
Additionally, to ensure that make distcheck continues to work, it is recommended to add the following to the top-level Makefile.am file in automake(1)-based projects:
AM_DISTCHECK_CONFIGURE_FLAGS = \
--with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)
Finally, unit files should be installed in the system with an automake excerpt like the following:
if HAVE_SYSTEMD
systemdsystemunit_DATA = \
foobar.socket \
foobar.service
endif
...
</ENDQUOTE>
So it appears you should use systemdsystemunitdir and systemduserunitdir. How well Autotools supports it, well...
A quick grep on Fedora 31 using grep systemdsystemunitdir /bin/autoconf and grep -IR systemdsystemunitdir /usr/share shows no Autotools support yet. 7 years and counting...
Is there perhaps a better way of starting this app at boot time without systemd?
Systemd should be OK to start your app. Simply use systemctl(1) to enable and start them as you normally would.
Based on your GitHub and autobrightnesscam.service.in, I would not dick around with Autotools for this. You can waste copious amounts of time working around Autotols short comings (speaking from experience).
My configure.ac script (which is just a shell script) would copy autobrightnesscam.service.in to autobrightnesscam.service, and then use sed to copy-in the correct directories and files. Then, I would copy the updated autobrightnesscam.service to its proper location in AC_CONFIG_COMMANDS_POST. Maybe something like:
SERVICE_FILE=autobrightnesscam.service
SYSTEMD_DIR=`pkg-config systemd --variable=systemdsystemunitdir`
# Use default if SYSTEMD_DIR is empty
if test x"$SYSTEMD_DIR" = "x"; then
SYSTEMD_DIR=/etc/systemd/system
fi
AC_CONFIG_COMMANDS_POST([cp "$SERVICE_FILE" "$SYSTEMD_DIR"])
AC_CONFIG_COMMANDS_POST([systemctl enable "$SYSTEMD_DIR/$SERVICE_FILE"])
AC_CONFIG_COMMANDS_POST([systemctl start "$SERVICE_FILE"])
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
No. AC_CONFIG_HEADERS is for setting up configuration headers to support your build. It is rarely used for anything other than building a config.h recording the results of certain tests that Autoconf performs, and it is not as flexible as other options in this area.
If you have additional files that you want Autoconf to build from templates then you should tell Autoconf about them via AC_CONFIG_FILES. Example:
AC_CONFIG_FILES([Makefile AutoBrightnessCam.service])
But if some of the data with which you are filling that template are installation directories then Autoconf is probably not the right place to do this at all, because it makes provision for the installation prefix to be changed by arguments to make. You would at least need to work around that, but the best thing to do is to roll with it instead, and build the .service file under make's control. It's not that hard, and there are several technical advantages, some applying even if there aren't any installation directory substitutions to worry about.
You can do it the same way that configure does, by running the very same template you're already using through sed, with an appropriate script. Something like this would appear in your Makefile.am:
SERVICE_SUBS = \
s,[#]VARIABLE_NAME[#],$(VARIABLE_NAME),g; \
s,[#]OTHER_VARIABLE[#],$(OTHER_VARIABLE),g
AutoBrightnessCam.service: AutoBrightnessCam.service.in
$(SED) -e '$(SERVICE_SUBS)' < $< > $#
Also, how do I specify that the service file should land (i.e.
installed) in /etc/systemd/system?
You use Automake's standard mechanism for specifying custom installation locations. Maybe something like this:
sytemdsysdir = $(sysconfdir)/systemd/system
systemdsys_DATA = AutoBrightnessCam.service
Is there perhaps a better way of
starting this app at boot time without systemd?
On a systemd-based machine, systemd is in control of what starts at boot. If you want the machine to start your application automatically at boot, then I think your options are limited to
Configuring systemd to start it
Configuring something in a chain of programs ultimately started by systemd to start it
Hacking the bootloader or kernel to start it
There is room for diverging opinions here, but I think the first of those is cleanest and most future-proof, and I cannot recommend the last.
If a test wants to assert the file permission error, for example, writing to the root of file system, "go test" returns an syscall.EACCES error, while "bazel test" returns an syscall.EPERM. How to make the test passes in both "bazel test" and "go test"?
An example can be found here.
You can disable the sandbox by using bazel --spawn_strategy=standalone test //.... I suspect this will work around the problem.
However, you may want to consider whether writing to / is the behavior that you want to test. If you need to run code on a different operating system or inside a Docker container, you'll get different behavior in this case, so you could think about testing a more predictable code path, or mocking out the file access layer to isolate your tests from it.
I'm using Pentaho Data Integration (Spoon) 8.1. I'm trying to passing parameters to a transformation using the command line. I'm using the sample writeback.ktr. This is my line:
java -jar launcher\launcher.jar -lib ..\libswt\win64 -main org.pentaho.di.pan.Pan -initialDir "C:\Users\Sistemas\Documents\Pentaho-Data-Integration"\ -file:"C:\Users\Sistemas\Documents\Pentaho-Data-Integration\samples\trans\writeback.ktr" -param="arg1=Boris" -param="arg2=Pedro" -param="arg3=Cristian" -level:Minimal
But it keeps creating the file without the values I'm passing to. I'm also try these other ways:
-param:"arg1=Boris"
-param:arg1=Boris
I'm using this configuration. Nothing seems to work. Can anyone help me please
Thanks
Below is the sample:
pan.bat /file:C:\Pentaho_samples\repository\repository_export.kjb
"/param:rep_name=PDI2000" "/param:rep_user=admin" "/param:rep_password=password"
"/param:rep_folder=/public/dev"
"/param:target_filename=C:\Pentaho_samples\repository\export\dev.xml"
Check below link for more clarification.
https://help.pentaho.com/Documentation/8.0/Products/Data_Integration/Command_Line_Tools
Well... after trying different alternatives, finally got a solution:
pan.bat -file:C:\trans\writeback.ktr "PDI2000" "admin"
This way, my transformation took the parameters.
Thanks.
I edited my target scheme to run a script action after testing as below
Target Scheme -> Test (Debug) -> Post Actions
The script hw.sh had a simple command line call:
open /Applications/Safari.app/
It worked fine for the above script. When I changed it to the following
groovy http://frankencover.it/with -s /Users/sasokan/Downloads/MyProject
Nothing happened. How can I call this groovy application using a script.
I am also trying to run frankencover.it and had the same problem you did. I eventually found this answer on SO that lead me to a solution. I added the following before calling frankencover.it and it fixed the issue.
PATH=${PATH}:/usr/local/bin
I will further note that even if you use the full path to groovy in the command frankencover.it will fail internally because it cannot find 'lcov' for the same reason.