You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.
Created by c.hirschmann on 2011-07-23 11:22:58 +00:00
Assignee: mfriedrich
Status: Resolved (closed on 2011-07-23 19:23:26 +00:00)
Target Version: 1.5
Last Update: 2014-12-08 14:35:52 +00:00 (in Redmine)
Icinga Version: 1.10.0
OS Version: any
Observed behaviour:
After a system crash, in which ido2db had no chance to shut down propperly, it can't recover after the system has booted again, because ido2db's own socket get's in the way.
First thing I noticed were a lot of lines like the following in the system log:
icinga: idomod: Still unable to connect to data sink. 0 items lost, 1041 queued items to flush.
This soon escalated into:
icinga: idomod: Still unable to connect to data sink. 4410 items lost, 5000 queued items to flush.
I then noticed that the ido2db service wasn't running. When I tried to start it manually, it found it's old lock file, tested wether there was a process with the same PID that was apparently stored in that lock file and after finding no such process it tried to start and immediatley exited with the following message:
Could not bind socket: Address already in use
This error message is misleading, since there is no process blocking the network port and address.
But manually removing the old socket file fixed the problem.
This was observed on a system running the latest CentOS 5.6, with icinga 1.4.0, icinga-api 1.4.0, icinga-doc-1.4.0, icinga-gui 1.4.0, icinga-idoutils 1.4.0.
Expected behaviour:
ido2db should be able to recover without assistance after it has crashed.
After it apparently found the old lock file and discovered that there despite the lock file there was no other ido2db process running, it probably should remove the old socket just as it removes the old lock file.
This issue has been migrated from Redmine: https://dev.icinga.com/issues/1745
Created by c.hirschmann on 2011-07-23 11:22:58 +00:00
Assignee: mfriedrich
Status: Resolved (closed on 2011-07-23 19:23:26 +00:00)
Target Version: 1.5
Last Update: 2014-12-08 14:35:52 +00:00 (in Redmine)
Observed behaviour:
After a system crash, in which ido2db had no chance to shut down propperly, it can't recover after the system has booted again, because ido2db's own socket get's in the way.
First thing I noticed were a lot of lines like the following in the system log:
icinga: idomod: Still unable to connect to data sink. 0 items lost, 1041 queued items to flush.
This soon escalated into:
icinga: idomod: Still unable to connect to data sink. 4410 items lost, 5000 queued items to flush.
I then noticed that the ido2db service wasn't running. When I tried to start it manually, it found it's old lock file, tested wether there was a process with the same PID that was apparently stored in that lock file and after finding no such process it tried to start and immediatley exited with the following message:
Could not bind socket: Address already in use
This error message is misleading, since there is no process blocking the network port and address.
But manually removing the old socket file fixed the problem.
This was observed on a system running the latest CentOS 5.6, with icinga 1.4.0, icinga-api 1.4.0, icinga-doc-1.4.0, icinga-gui 1.4.0, icinga-idoutils 1.4.0.
Expected behaviour:
ido2db should be able to recover without assistance after it has crashed.
After it apparently found the old lock file and discovered that there despite the lock file there was no other ido2db process running, it probably should remove the old socket just as it removes the old lock file.
Attachments
Changesets
2011-07-23 18:19:21 +00:00 by mfriedrich 2b9eece
Relations:
The text was updated successfully, but these errors were encountered: