[PATCH] core: Don't free the lock file path too soon

Robin Sonefors robin.sonefors at op5.com
Wed May 22 10:41:24 CEST 2013


It's used after the main loop ends in the main function to remove the
lock file once we're shut down.

As the variable was already freed and pointed to NULL, unlink would not
remove the lock file, but instead return EFAULT. This is not how daemons
are supposed to behave.

Signed-off-by: Robin Sonefors <robin.sonefors at op5.com>
---
 base/utils.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/base/utils.c b/base/utils.c
index 5e038cb..362e683 100644
--- a/base/utils.c
+++ b/base/utils.c
@@ -2902,7 +2902,6 @@ void free_memory(nagios_macros *mac) {
 	my_free(command_file);
 	mac->x[MACRO_COMMANDFILE] = NULL; /* assigned from command_file */
 	my_free(log_archive_path);
-	my_free(lock_file);
 
 	for (i = 0; i < MAX_USER_MACROS; i++) {
 		my_free(macro_user[i]);
-- 
1.7.11.7


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may




More information about the Developers mailing list