when using AMQ 5.6 and starting the broker using ./activemq start...where does the stdout/stderr go?
I expected it to show up in the /data/activemq.log file, but it doesn't...is there are way around this with a tweak to the log4j or JavaServiceWrapper config perhaps?
When I start in console mode using ./activemq console, the stdout/stderr messages are displayed as expected. In particular, I need to get output from e.printStackTrace() to show up in the logs when running in this mode.
it seems to just get redirected to /dev/null...I changed the /bin/activemq script to redirect to ../data/start.log instead and sure enough, the stdout/err are there...not sure why this isn't the default behavior to be honest...
When i remember correctly, there is another file called wrapper.log. look out for it in the same dir where wrapper.conf is.
Related
Sorry for my noob question as I am very new to linux. Please consider the below linux command :
/opt/mongodb-mms-automation/bin/mongodb-mms-automation-agent
-f /etc/mongodb-mms/automation-agent.config
-pidfilepath /var/run/mongodb-mms-automation/mongodb-mms-automation-agent.pid
>> /var/log/mongodb-mms-automation/automation-agent-fatal.log 2>&1
According to my understanding >> redirects standard output to file and 2>&1 means that standard error will be redirected to the same location as standard output. So in the above case I expect the standard output and standard error both to be redirected to /var/log/mongodb-mms-automation/automation-agent-fatal.log.
But obviously this is not the case. I can see that all info / error messages are being redirected to a file /var/log/mongodb-mms-automation/automation-agent.log. Can someone please explain what error I am making in reading this command?
Regards,
Meena
Standard output and standard error are just default destinations; the program could be doing a number of things which will sabotage any attempts to save the logs by redirecting to a file:
It writes straight to the terminal output, such as /dev/pts/0.
It detects whether standard output/error are connected to a file or a terminal, and changes behaviour accordingly.
Anything else the application developer considered to be the most useful behaviour.
In other words, it's application specific. You're probably better off finding the logfile configuration setting and changing that if you really need to. Usually I find it's easier and safer to leave the defaults (since they may be handy for example for security reasons such as sandboxing) and instead pointing to the default location in whatever software is trying to process that file in some way.
I am using rsyslog to relay events from a machine to Loggly (cloud log management). I have an application running on that machine that logs to the local rsyslog by using the SyslogAppender of log4net. However, since some of the events are multi-line, thus contain new lines which are then replaced by the escape sequence #012. However, I would like to replace the newlines in the message part to <br/>. I have looked at rsyslogs property replacing [1] feature but I am not really sure if this is the right way. Furthermore, changing the implementation of the application would require some effort so I would like to avoid this way. So I am looking for a way to solve this issue "outside" of my application.
Thanks in advance for any help or suggestions!
[1] http://www.rsyslog.com/doc/property_replacer.html
It seems that the #12s is getting produced by log4net - not by syslog. If you don't want to change the application, you can use sed to replace the #12 by <br/>:
sed 's/#12/\n/g' logfile
I have a rsyslog daemon running on a server receiving and aggregating messages from a number of other servers. Occasionally, I see line written which looks like the start of a message, an ellipsis(...), and the end of another, different, message.
It doesn't appear to have anything to do with the length of the message, as longer messages get through with out problems.
I have looked through the rsyslog doco without success and searching google for ... is not useful. Have I just missed something in the doco, or is this a bug?
The elipsis is actually coming from the log4j syslog appender implementation. If the line is "too long" it will be truncated and an elipsis will be written instead.
I would like to print some messages and variable values while my configuration is applied.
I would also like to separate the output of different configuration blocks visually. so I use
notify {"\n\nINSTALL TOMCAT TO $target_folder":}
as described in puppet tutorials and documentation.
Unfortunately the output does not really add readability to the whole log:
notice:
INSTALL TOMCAT TO /opt/example/uiserver
notice: /Stage[main]//Node[dev-xyz.example.com]/Tomcat[uiserver_tomcat]/Notify[
INSTALL TOMCAT TO /opt/example/uiserver]
INSTALL TOMCAT TO /opt/example/uiserver'
Problem - instead of just printing the message, puppet also outputs an annoying echo /message: defined 'message' as '. Is there any way to eliminate it?
Using withpath => false did not help.
Puppet 2.7.17.
Set --logdest to syslog.
It's console by default.
--logdest:
Where to send messages. Choose between syslog, the console, and a log
file. Defaults to sending messages to the console.
Maybe try using the notice() function instead of the notify type as per http://www.puppetcookbook.com/posts/simple-debug-messages.html
With the notice() function mesagee will be written to the puppetmaster's log instead of the client, but there won't be an echo line echo'd back.
I building my sites on the localhost (runs wamp on windows), and when I upload it to my server, I always get
"Cannot modify header information - headers already sent"
I understand that there shouldn't be any blank lines and everyhing, and usually this works out. but now I need to redirect someone after the header has been sent, how can I make my server act like my localhost ?
i'm using cpanel and WHM:
cPanel 11.25.0-R42399 - WHM 11.25.0 - X 3.9
CENTOS 5.4 x86_64 virtuozzo on vps
I will appreciate any help
In short, you need to prevent PHP from outputting anything to the browser before you get to the point where you want to use the header() function.
This should be done by careful programming practices, of which your 'no blank lines' is one, or by storing PHP's output in an output buffer, and only outputting when you're ready for it.
See the ob_start() and ob_flush() methods. You use ob_start() at the start of your application. This disables output and stores it into a buffer. When you're ready to start outputting, use ob_flush() and PHP will send the buffer's contents to the browser, including the headers that are set till that point. If you don't call ob_flush() then the buffer is output (flushed) at the end of the script.
The reason why it works on your WAMP development environment is most likely that output buffering is already enable by default in the php.ini. Quite often these all-in-one packages enable a default buffer for the first 4k bytes or so. However, it is generally better to explicitly start and flush the buffer in your code, since that forces better coding practices.
Well,
I guess by more thinking and better programing you can manage to keep all redirects before any HTML is written.
This problem solved by the old rules...
#user31279: The quickest and dirtiest way I know of is to use # to suppress the warning, so e.g.
#header('Location: some-other-page.php');