I'm running rsyslog 5.8.11 on debian 7.11, standard installation (local, no remote logging).
I've noticed that about 2 minutes after being started, rsyslog stops writing messages to the log files. It's still "running", it just doesn't do anything. I can manually restart it, and it works for another couple of minutes.
Any idea how I can fix that?
Thanks in advance
I finally found out: another program was stalling.
For some reason, it was making rsyslog stalling, which in turn was making postfix stalling.
Weird!
Related
I have an OS which doesn't shut down properly when I run it in one particular hypervisor (KVM) even though it works on all other hypervisors. Instead, what it does is sync all data to disk and then hang indefinitely with the message "Hit any button to reboot" until you issue a hard shutdown from the hypervisor.
I'm trying to automate a no-touch installation of this OS from an .iso file into a .box file using Packer. However, the Packer run fails every time because it hits the shutdown_timeout (from the QEMU builder) while the OS is hung waiting for input. I'm looking for a workaround -- it seems like either of the following could work (and maybe there are other ways), but I can't figure out any way to do them! Some ideas I've searched for were:
tell Packer to do a hard shutdown after a certain amount of time
tell Packer that hitting this timeout isn't an error and it should just do a hard shutdown and continue with the provisioner steps
Upon rereading the docs, I found the answer:
shutdown_command (string) - The command to use to gracefully shut down the machine once all the provisioning is done. By default this is an empty string, which tells Packer to just forcefully shut down the machine.
D'oh!
I've been using SonarQube for a year now and once I had been through all the installation process, I never got any problem... Until now.
I'm just trying to analyze a Maven Project (like I did several times before). To do so, I need to run the server first (port 9000). But when I launch "StartSonar.bat" (I'm on Windows), I get a huge log and finally the wrapper stops.
I think there is something wrong with the port 9000 although I'm not sure because I'm not that advanced with analysing logs and everything.
Here's a link to download the log I get
Thanks for your help!
The log states "Address already in use: bind" which means that some other tool already runs on that port. Choose another one should already do the trick.
Or there is a zombie-process still running (no clean shutdown). But you should see a process in the task manager - just kill that one. Usually a reboot should solve that too.
Run netstat -abo on the Windows command line to see which ports are used, by which programs they are used and their process IDs (PID). With the PID you can find the process in Task Manager and kill it there if necessary.
Anyone ever experienced something like that? I'm installing OpenCMS 8.5.0. for evaluation, running on Tomcat 7x, and during the 8th step of setup (Installing Modules), the process freezes - I've got stuck for a long time in a same line (I left it the way it was, and hung out for coffee for 30-40 minutes), without any update.
What have you done?
Thanks,
*** Edited from this line ***
I've tried to refresh the page (After coming back from my coffee break), and it only cleared the logs. So I stopped the server and re-started it again. The process started from beginning (I had to drop the database and create it again), the processes freezes again, I waited some time, a tried to refresh the page sometimes, again I faced logs inside the 'textarea' the being cleared, after some tries, the process was finally finished.
Anyone have faced the same experience?
Things to check:
How much max. heap is assigned to the Tomcat? 64MB as the default standard? Eventually tried to increase that parameter?
Can ou check the log (WEB-INF/logs/opencms.log) or the catalina.out - do you see any errors in there?
I have OpenCms 8.5 running on Tomcat7 without any problems.
Which OS are you on? Windows, Linux, Mac?
I'm having a very strange problem. I'm using dfs-datastores Pail abstraction to write data to HDFS in Java. I don't think the Pail piece is important to the problem though.
When it calls org.apache.hadoop.fs.FileSystem getFS(java.lang.String path) with a path on my local filesystem it pauses for about 2 minutes seemingly doing nothing then returns. This is on my laptop.
The weird thing is that it worked really fast when I was on the network at my office today, but now that I'm home it's doing it again. I'm running Ubuntu 10.10 64-bit with Java 1.7.
Anyone have any ideas what it's doing? What could be different between being at work and being at home?
UPDATE:
I've been stepping through code with the debugger and it seems to be having trouble in Configuration.loadResource(). It's calling that multiple times and it will take 5-10 seconds to return from that function.
UPDATE2:
I've narrowed this down a little further. The biggest hang up seems to be when it calls KerberosName.setConfiguration(). Which would explain why it runs fast at work since the Active Directory acts as a Kerberos server. I don't have one here at home, so it can't find one. Now they question is why in the world it's trying to load the Java Kerberos stuff.
I found a solution (or at least a work around). I installed the krb5-kdc package and now my little program runs fast without any unexplained pauses. After this I removed krb5-kdc, tested and it was still running fast. I removed /etc/krb5.conf and it started doing the pause again. It looks like using the Hadoop library on Ubuntu (at least) requires a /etc/krb5.conf file.
Maybe this will help someone else.
I'm getting this error message every 10 seconds.
2011-02-09 05.54.37 com.apple.launchd.peruser.501[153] (com.mysql.mysqld) Throttling respawn: Will start in 10 seconds
I'm running OS X 10.6.6.
Anyone knows what the problem may be and how do solve it?
This is a situation that's been around in Unices for donkey's years. Your program is exiting immediately as soon as it is invoked, leading to it be restarted over and over by launchd. launchd has noticed this and stopped respawning the program. The standard advice on this goes back many years, too: Find out why the daemon process is immediately exiting rather than running, and fix the cause of that. (It's usually a daemon misconfiguration of some kind.)
Yes, technically, in Mac OS 10 speak this is an "agent" rather than a "daemon", but that doesn't change either the nature of the problem or what you have to do to fix it.
http://web.archive.org/web/20101024201347/http://blog.sirkevi.com/files/Removing_MacOSX_software_that_are_constantly_relaunched.php
Quoting:
These following commands helped a lot
launchctl list -> shows a list of autostart services
launchctl remove com.webex.asassist
launchctl remove com.webex.taskwatcher