Skip to content
Networks, Applications and Event Monitor
C Shell Makefile Python M4 Perl Other
Branch: master
Clone or download
sni fix downtime tests
it is unsafe to access the downtimes after they have been removed because this
frees the underlaying memory. This might work sometimes if the memory has not
been reused meanwhile but is undefined behaviour.
The effect of has been asserted indirectly through the affected hosts/service already.

Signed-off-by: Sven Nierlein <>
Latest commit 10b568e Aug 21, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
contrib cleanup contrib folder May 29, 2018
debian release 1.0.10 Mar 19, 2019
features Log successful save of retention data Sep 4, 2018
lib Mark intentional fallthroughs in switch statements Mar 9, 2018
sample-config Corrected retained window typo in sample-config Dec 18, 2018
t fix expanding service dependencies May 13, 2019
tap Remove files which get generated by autoreconf May 24, 2016
tests fix downtime tests Aug 22, 2019
.gitignore decouple core, livestatus and thruk May 29, 2018
.travis.yml Revert "Merge pull request #59 in MONITOR/naemon from bugfix/revert-d… Apr 21, 2017
AUTHORS Start fixing the autotools machinery Nov 22, 2013
COPYING Re-add COPYING file with license Oct 10, 2018
ChangeLog Added changelog for 1.0.7 release Jun 1, 2018
LEGAL Remove ancient copyright notice Mar 19, 2014 make buildopts.h depend on Makefile May 29, 2018
NEWS release 1.0.10 Mar 19, 2019
README Start fixing the autotools machinery Nov 22, 2013 Fix url to in README Feb 11, 2014
THANKS Import the code Nov 1, 2013
UPGRADING finally get rid of the old html files and cgis Nov 22, 2013
acinclude.m4 autotools: Detect supported compiler flags Dec 10, 2013 rpm: fix sles packaging Jun 1, 2018
behave.ini update all versions of logrotate files. Jun 2, 2017 Init: Increase time till SIGKILL is sent Sep 4, 2018 Make systemd startup cleaner May 29, 2018
functions Import the code Nov 1, 2013 New indent rules Dec 3, 2013 New indent rules Dec 3, 2013
naemon-core.spec release 1.0.10 Mar 19, 2019 Revert "Merge pull request #59 in MONITOR/naemon from bugfix/revert-d… Apr 21, 2017 naemon: Obsolete naemon_user & naemon_group options Mar 2, 2015 logrotate: Specify which user/group the logrotate will be run as Jun 2, 2017 logrotate: Specify which user/group the logrotate will be run as Jun 2, 2017 naemon: Obsolete naemon_user & naemon_group options Mar 2, 2015
naemon.rpmlintrc decouple core, livestatus and thruk May 29, 2018
naemon.tmpfiles.conf Add native systemd support Feb 24, 2014 Revert "test: So, tap-driver is installed by autoreconf" Feb 25, 2014 fix query handler not returning command response Dec 11, 2018 release 1.0.10 Mar 19, 2019

Welcome to Naemon Core

Naemon is a host/service/network monitoring program written in C and released under the GNU General Public License. It works by scheduling checks of the configured objects and then invoking plugins to do the actual checking. The plugin interface is 100% Nagios compatible, since Naemon is a fork of the aforementioned project.


Contributing to Naemon is meant to be easy, fun and profitable. I'm not sure where the profit will come from, but if you get a warm glow of pride when getting a patch accepted, you can consider that your reward if you like.

The easiest way is probably to fork this project on github, and then send pull requests to the original project. You can also send patches to

Commit messages

Commit messages MUST contain a Signed-off-by line and have a proper author name and email address (even though "Anonhacker42 is considered "proper" in these circles). If you run git commit -s you'll get the signed-off-by for free. The signed-off-by indicates that you're telling us you have the right to submit this patch and that we shouldn't worry about lawyers from whatever company you're working for will come at us later and demand that we remove your contributions from the code. It might not be much of a protection against such things, but it's more or less standard praxis in the git-using projects, so please just stick to it, ok?

Messages MUST contain a brief statement of why the change was made. "Fix bugs" is a bad message, as it means people will have to know which bugs you're fixing. "Make sure we don't segfault when the disk is full" is a useful message, because it points to a problem and makes it clear that the patch should fix it. In case deep analysis was required in order to figure out the root cause of the problem, you're encouraged to also write your findings there. It also makes it look as if you did a whole lot of work and did it thoroughly, which is pretty good for your resumé.

Messages SHOULD be written in imperative form, as if you're giving the code orders on how it should change. It provides a much nicer basis for discussion when a patch has to be reviewed online, as it indicates that the change is about to take place but is open for discussion rather than that it already has and that discussion isn't welcome.

Messages SHOULD have lines shorter than 72 chars. Most of the time, people will inspect logs or blame output in a terminal or in a limited width program, and it's a pain to have to scroll sideways all the time to see the message. Please keep the lines short and it'll save some annoyance on behalf of other people.

Coding standards

Common sense applies.

  • Don't break backwards compatibility without a really good reason.
  • Don't remove or alter API's unless absolutely necessary.
  • Don't write huge functions that do a lot. It's hard to test those, and we do like tests.
  • Use the indentation already found in the files, or reindent to your liking and then run "sh" when you're done. That should bring the tree back to some semblance of unity.
  • Avoid sending patches with a lot of whitespace changes. They're hard to review so they probably won't be.
  • Don't engage in useless codechurn. If the patch you're submitting doesn't solve an actual problem or paves the way for solving some sort of problem or adding a feature, it's most likely not worth the trouble.


When installing from a released tarball, all you need to do is to run

sudo make install

If you want to help out with development and hence download the source from git, you instead need to run

sudo make install

More info

Visit the Naemon homepage at

You can’t perform that action at this time.