Is there a way to change the verbosity of the idb_companion --notify stdout verbosity?
Related
When running the Neo4j standalone community Docker, some logs are written to stdout and some to a file inside the container: debug.log.
I would like to be able to set log4j options, like log-level, appenders etc. The reasons are:
I can't access the log files when running in e.g AWS ECS
The debug logs are quite verbose
log4j-properties are convenient to deploy and manage
So the question is, how can I set a custom log4j properties for a Neo4j server that's running inside a container?
It's not documented if it's even possible, but I have tried the usual things one starts to thing of. First adding a log4j.xml to the classpath but to no avail. Also I have tried setting dbms.jvm.additional to
-Dlog4j.configuration=<path_to_file>
-Dlog4j.configurationFile=<path_to_file>
-Dlog4j2.configurationFile==<path_to_file>
I've verified that the Neo4j process has the correct jvm-arguments:
/usr/local/openjdk-11/bin/java -cp /var/lib/neo4j/plugins:/var/lib/neo4j/conf:/var/lib/neo4j/lib/*:/var/lib/neo4j/plugins/*
-Xms2048m -Xmx2048m -XX:+UseG1GC -XX:-OmitStackTraceInFastThrow -XX:+AlwaysPreTouch
-XX:+UnlockExperimentalVMOptions -XX:+TrustFinalNonStaticFields -XX:+DisableExplicitGC
-XX:MaxInlineLevel=15 -XX:-UseBiasedLocking -Djdk.nio.maxCachedBufferSize=262144
-Dio.netty.tryReflectionSetAccessible=true -Djdk.tls.ephemeralDHKeySize=2048
-Djdk.tls.rejectClientInitiatedRenegotiation=true -XX:FlightRecorderOptions=stackdepth=256
-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints -Dlog4j2.disable.jmx=true
-Dlog4j.configuration=file:/var/lib/neo4j/conf/log4j.properties
-Dlog4j.configurationFile=file:/var/lib/neo4j/conf/log4j.xml
-Dlog4j2.configurationFile=file:/var/lib/neo4j/conf/log4j2.xml
-Dfile.encoding=UTF-8 org.neo4j.server.CommunityEntryPoint
--home-dir=/var/lib/neo4j --config-dir=/var/lib/neo4j/conf
I have verified that no lib-jars contains a log4j-properties that takes precedence.
And whatever I try, no changes are made to the way the server is logging. The same events are written to /logs/debug.log. No exceptions regarding bad log4j config or something like that.
I have created a small project for easier debugging.
I would write out the files to stdout.
# forward logs to docker log collector
RUN ln -sf /dev/stdout /logs/debug.log
So this is a 'docker' solution but handy and works also for other usecases.
Overly verbose logs produced by 3rd party libraries can be hidden in Swift by setting OS_ACTIVITY_MODE environmnet variable to disable in your run scheme - as shown on the image below.
That silences all NSLog output from your app. I want to disable it only for certain calls. I tried to set the environment variable like this:
setenv("OS_ACTIVITY_MODE", "disable", 1)
And like this
putenv(UnsafeMutablePointer<Int8>(mutating: ("OS_ACTIVITY_MODE=disable" as NSString).utf8String))
The environment is changed as verified by calling print(ProcessInfo.processInfo.environment) but there unlike specifying it in XCode run scheme, the logs are not affected.
Why doesn't it work and how to fix it?
When you set OS_ACTIVITY_MODE to disable, you disable all log outputs for processes that have access to this environment variable, for example the simulators.
When you set the value to either info or debug it enables the corresponding logging mode unless it is disabled in the logging preferences for certain log categories.
So in order to enable only a certain log category, you have to enable OS_ACTIVITY_MODE, that is, set it either to info or debug or leave it at the default, and then disable logging for all other categories.
For more information how to do this see the man page for log, type man log in the console.
Get the current log preferences for simulators:
In the console type:
xcrun simctl spawn booted log config --status
That basically means: apply log config -status to all booted simulators.
This may print the following to your console:
System mode = INFO STREAM_LIVE PRIVATE_DATA
Get the status for a certain category and subsystem
xcrun simctl spawn booted log config --status --subsystem com.mycompany.myapp --category network
This may print the below to the console:
Mode for 'com.mycompany.myapp(network)' INFO PERSIST_DEFAULT
Get Help
For help, the tools xcrun simctl and log have nifty man pages and help pages.
For example:
type log config --help into the console, it prints:
usage: log config [options] --mode <modes>
or: log config [options] --status
or: log config [options] --reset
description:
Read or configure settings for the logging system. Configuration
can act system-wide; or on a subsystem, category, or process level.
options:
--category <name> Get/set settings for a given category
--mode <modes> Enable given modes
--process <pid> | <name> Get/set settings for a given process
--reset Reset settings to defaults
--status Show current settings
--subsystem <name> Get/set settings for a given subsystem
modes:
Modes can be specified as a comma-separated list of key:value pairs.
Valid keys and their values are:
level off | default | info | debug
persist off | default | info | debug
stream live | default
Set the log level for a specific subsystem and category
xcrun simctl spawn booted log config --mode "level:debug" --subsystem com.mycompany.myapp --category network
Get the status again for this sybsystem and category will print:
Mode for 'com.mycompany.myapp(network)' DEBUG PERSIST_DEFAULT
Because environment variables are usually read only once, when the program starts.
In libdispatch 442.1.4, the OS_ACTIVITY_MODE variable is read in _voucher_init to determine a value of an internal variable; _voucher_init is in turn called in libdispatch_init, which is called only once at program startup. Interestingly, I cannot find this code in later versions of the library; perhaps it has been moved somewhere else. But it doesn’t really matter; the same principle applies. Setting the value of an environment variable will usually have no effect on already-initialised code, and can only be used to influence child processes.
As for solutions, I don’t have an easy one. Personally, I would try finding some method to disable logging in the specific library in question, or to filter the messages out: in the worst case, I’d put a couple of my own NSLog calls with messages controlled by me before and after calls to the library, and tell a filter to ignore everything between the two.
I would check the uwsgi config before restarting it, because if it is not valid, it should give warning and does not restart.
1) Can i solve this with writing some kind of plugin or using hook?
I've found a phase (as-user-atexit) to which i can attach a hook (exec some kind of shell commands), but i don't see how can i prevent restarting.
2) Or should i solved this on level overwriting systemd unit script?
you may want to check this http://uwsgi-docs.readthedocs.io/en/latest/FallbackConfig.html for an alternative approach
In ant when running a command with the exec task anything written to stdout or stderr in the child process has " [exec] " prepended to every line written to both the console and the log file. Is there a way to suppress this behavior or explicitly supply the prefix? (ie: to "" or maybe just an indent)
This is because an ant build run in an IDE the prefix scrambles the ability of the IDE to jump to source files by clicking on the output error messages from javac and other compilers
You may run ant with -emacs option.
However in this case it will suppress the prefix for all tasks.
Otherwise you may implement your own log handler.
In an interactive terminal on MacOS, I successfully sidestepped the Ant log-wrapping mechanism on the exec task by means of the /dev/stdout and /dev/stderr devices, as follows:
<exec executable="python" output="/dev/stdout" error="/dev/stderr">
<arg line='myscript.py' />
</exec>
This will probably also work on Linux, though I havn't explicitly tested it.
On Windows it also works using output="con" error="con" (though in my case, tty codes from my script won't work in a Windows cmd terminal).
I'm using supervisord as the entry point for Docker containers as described in https://docs.docker.com/articles/using_supervisord/,
I want all logs to be written to stdout so I can take advantage of builtin tools like docker logs or systemd's journal, especially if running the containers on CoreOS.
for stderr there's redirect_stderr=true option for subprocesses,
is it possible to redirect the subprocess stdout back to supervisord somehow and not deal with actual log files ?
You can redirect the program's stdout to supervisor's stdout using the following configuration options:
stdout_logfile=/dev/fd/1
stdout_logfile_maxbytes=0
Explanation:
When a process opens /dev/fd/1 (which is the same as /proc/self/fd/1), the system actually clones file descriptor #1 (stdout) of that process. Using this as stdout_logfile therefore causes supervisord to redirect the program's stdout to its own stdout.
stdout_logfile_maxbytes=0 disables log file rotation which is obviously not meaningful for stdout. Not specifying this option will result in an error because the default value is 50MB and supervisor is not smart enough to detect that the specified log file is not a regular file.
For more information:
http://veithen.github.io/2015/01/08/supervisord-redirecting-stdout.html