Re: [Openais] [PATCH] trunk: logsys, do not flood syslog with debugging info
On Fri, 2008-07-11 at 12:55 +0200, Fabio M. Di Nitto wrote: > On Fri, 11 Jul 2008, Fabio M. Di Nitto wrote: > > > > > Hi Steven, > > > > syslog should generally get only relevant messages for sysadmin tasks. All > > debugging output should go only to_file/logfile. > > > > the patch filters LOG_LEVEL_DEBUG messages from being sent to syslog. > > > > Please apply. > > > > Fabio > > > > New patch based on IRC discussion. > > Please apply > > Fabio > I missed this discussion. This patch is much better. -- Lon ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] [PATCH] trunk: logsys, do not flood syslog with debugging info
On Fri, 2008-07-11 at 09:33 +0200, Fabio M. Di Nitto wrote: > Hi Steven, > > syslog should generally get only relevant messages for sysadmin tasks. All > debugging output should go only to_file/logfile. > > the patch filters LOG_LEVEL_DEBUG messages from being sent to syslog. > > Please apply. Syslog filters messages too. "debug.* /dev/null" would do it. I must disagree with this patch. It means administrators *CAN NOT* enable debugging to syslog even if they want to, and that they must use file I/O even if they do not want to just to debug something. -- Lon ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] [Linux-cluster] Lost token - every 5 minutes: [TOTEM] The token was lost. Samba process possible cause?
Hi, This sounds like something that someone on the openais would know. I've CC'd the openais list. -- Lon On Fri, 2008-06-27 at 16:03 +1000, Bevan Broun wrote: > Hi All > > I have a 2 node RHEL-5.1 cluster. A quorum disk is configured. > The hosts have 4 NICs. These are bonded: > (eth0+eth2) -> bond0 > (eth1+eth3) -> bond1 > Unfortunately I was not able to use a dedicated interface for cluster > communications - bond1 is being used. This is where I think Im in trouble. > > The cluster has been configured using IP addressess. I did have to use > http://archives.free.net.ph/message/20080130.074958.5c7a211c.en.html > as the hostname is related to the bond0 IP. > > I have not defined the interface to be used by the cluster, just relying on > the IP address configured. > The cluster's purpose is 2 GFS file systems. > > The cluster was configured and working for 4 days before there was problems. > > I now have almost constant lost of token message in /var/log/message. They > are almost exactly 5 minutes apart. A typical bit of messages file is show > below my sig. > > Just before the problem started a samba message shows nmdb becomming local > master browser for a work group on the interface used for cluster > communications. > > Jun 20 13:39:27 HOST1 nmbd[24506]: [2008/06/20 13:39:27, 0] > nmbd/nmbd_become_lmb.c:become_loca > l_master_stage2(396) > Jun 20 13:39:27 HOST1 nmbd[24506]: * > Jun 20 13:39:27 HOST1 nmbd[24506]: > Jun 20 13:39:27 HOST1 nmbd[24506]: Samba name server NBM1 is now a local > master browser for > workgroup SMS_DOMAIN on subnet 162.16.96.229 > Jun 20 13:39:27 HOST1 nmbd[24506]: > Jun 20 13:39:27 HOST1 nmbd[24506]: * > Jun 20 13:43:27 HOST1 openais[15265]: [TOTEM] The token was lost in the > OPERATIONAL state. > > "cman_tool status" shows both nodes and looks normal. Looks like clmvd is not > happy, df commands are hanging. > > Could nmdb be causing this token loss? Any ideas on how to proceed? > > (names and IPs have been changed). > > Thanks > > Bevan Broun > Solutions Architect > Ardec International > http://www.ardec.com.au > http://www.lisasoft.com > http://www.terrapages.com > Sydney > --- > Suite 112,The Lower Deck > 19-21 Jones Bay Wharf > Pirrama Road, Pyrmont 2009 > Ph: +61 2 8570 5000 > Fax: +61 2 8570 5099 > > > > Jun 20 13:48:31 HOST1 openais[15265]: [TOTEM] The token was lost in the > OPERATIONAL state. > Jun 20 13:48:31 HOST1 openais[15265]: [TOTEM] Receive multicast socket recv > buffer size (28800 > 0 bytes). > Jun 20 13:48:31 HOST1 openais[15265]: [TOTEM] Transmit multicast socket send > buffer size (2621 > 42 bytes). > Jun 20 13:48:31 HOST1 openais[15265]: [TOTEM] entering GATHER state from 2. > Jun 20 13:48:31 HOST1 openais[15265]: [TOTEM] Creating commit token because > I am the rep. > Jun 20 13:48:31 HOST1 openais[15265]: [TOTEM] Saving state aru 16 high seq > received 16 > Jun 20 13:48:31 HOST1 openais[15265]: [TOTEM] Storing new sequence id for > ring 20ce34 > Jun 20 13:48:31 HOST1 openais[15265]: [TOTEM] entering COMMIT state. > Jun 20 13:48:41 HOST1 openais[15265]: [TOTEM] The token was lost in the > COMMIT state. > Jun 20 13:48:41 HOST1 openais[15265]: [TOTEM] entering GATHER state from 4. > Jun 20 13:48:41 HOST1 openais[15265]: [TOTEM] Creating commit token because > I am the rep. > Jun 20 13:48:41 HOST1 openais[15265]: [TOTEM] Storing new sequence id for > ring 20ce38 > Jun 20 13:48:41 HOST1 openais[15265]: [TOTEM] entering COMMIT state. > Jun 20 13:48:51 HOST1 openais[15265]: [TOTEM] The token was lost in the > COMMIT state. > Jun 20 13:48:51 HOST1 openais[15265]: [TOTEM] entering GATHER state from 4. > Jun 20 13:48:51 HOST1 openais[15265]: [TOTEM] Creating commit token because > I am the rep. > Jun 20 13:48:51 HOST1 openais[15265]: [TOTEM] Storing new sequence id for > ring 20ce3c > Jun 20 13:48:51 HOST1 openais[15265]: [TOTEM] entering COMMIT state. > Jun 20 13:49:01 HOST1 openais[15265]: [TOTEM] The token was lost in the > COMMIT state. > Jun 20 13:49:01 HOST1 openais[15265]: [TOTEM] entering GATHER state from 4. > Jun 20 13:49:01 HOST1 openais[15265]: [TOTEM] Creating commit token because > I am the rep. > Jun 20 13:49:01 HOST1 openais[15265]: [TOTEM] Storing new sequence id for > ring 20ce40 > Jun 20 13:49:01 HOST1 openais[15265]: [TOTEM] entering COMMIT state. > Jun 20 13:49:06 HOST1 openais[15265]: [TOTEM] entering RECOVERY state. > Jun 20 13:49:06 HOST1 openais[15265]: [TOTEM] position [0] member > 162.16.96.229: > Jun 20 13:49:06 HOST1 openais[15265]: [TOTEM] previous ring seq 2149936 rep > 162.16.96.229 > Jun 20 13:49:06 HOST1 openais[15265]: [TOTEM] aru 16 high delivered 16 > received flag 1 > Jun 20 13:49:06 HOST1 openais[15265]: [TOTEM] position [1] member > 162.16.96.230: > Jun 20 13:49:06 HOST1 openais[15265]: [TOTEM] previous ring seq 2149936 rep > 162.16.96.229 > Jun 20 13:49:06 HOST1 openais[15265]: [TOTEM] aru 16 high delivered 1
[Openais] [PATCH] trunk: Update logsys_overview man page to reflect new modes
As requested, this updates the logsys_overview man page to reflect the
changes in my previous patch.
* Adds documentation for the LOG_MODE_NOSUBSYS mode flag,
* Adds documentation for the LOG_MODE_SHORT_FILELINE mode flag, and
* Fixes (typo) 'declartion' -> 'declaration'
-- Lon
Index: logsys_overview.8
===
--- logsys_overview.8 (revision 1571)
+++ logsys_overview.8 (working copy)
@@ -42,19 +42,19 @@
.PP
Support for 8 tracing levels and tracing the entering and leaving of functions
.PP
-Declartion of logging system or subsystem without calling any functions
+Declaration of logging system or subsystem without calling any functions
.PP
Dynamic reconfiguration of the logging system parameters
.PP
Logging to syslog, file, stderr.
-.SH Declartion of the System logger
+.SH Declaration of the System logger
The logsys library is initially configured by including logsys.h and declaring
a logger. Once the logger is declared either a subsystem logger or nosubsystem
logger is declared in every file.
The definition LOGSYS_DECLARE_SYSTEM is placed after the include section of one
-C file in the application. This declartion creates a constructor function
+C file in the application. This declaration creates a constructor function
which will be called automatically. This technique avoids the need for calling
any setup functions in short applications that don't require it.
@@ -62,22 +62,24 @@
The name parameter is the name of the application.
The mode parameter is the logging mode of the system. The following modes
can be configured by logically ORing these flags:
-LOG_MODE_OUTPUT_FILE: Output all log data to the file parameter of this declartion
+LOG_MODE_OUTPUT_FILE: Output all log data to the file parameter of this declaration
LOG_MODE_OUTPUT_STDERR: Output all log data to the stderr descriptor
LOG_MODE_OUTPUT_SYSLOG_THREADED: Output all log data to syslog using a non-blocking thread
LOG_MODE_OUTPUT_SYSLOG_LOSSY: Output all log data without using a thread but potentially losing data. This mode is not yet implemented.
LOG_MODE_OUTPUT_SYSLOG_BLOCKING: Output all log data without using a thread and potentially blocking at each syslog call.
LOG_MODE_DISPLAY_PRIORITY: Output the priority of the log entry in the message contents. This mode is currently not implemented.
LOG_MODE_DISPLAY_FILELINE: Output the file and line at which the log message was created.
+LOG_MODE_SHORT_FILELINE: When using LOG_DEBUG level or LOG_MODE_DISPLAY_FILELINE, typically the absolute path to the file (derived at compile-time) is displayed. Enabling this flag ensures that only the filename and line are displayed.
LOG_MODE_DISPLAY_TIMESTAMP: Output the timestamp of the message.
LOG_MODE_BUFFER_BEFORE_CONFIG: This mode is used to buffer log messages before logsys_mode_config is called. This is useful in applications in which the logging file isn't known before the application is compiled and must be set dynamically. It is also useful when an application calls fork to disconnect the local tty and should hold logging of messages until after the fork.
-LOG_MODE_FLUSH_AFTER_CONFIG: This mode is used to flush any buffered messages when the LOG_MODE_BUFFER_BEFORE_CONFIG declartion is specified in the declartion of the logger.
+LOG_MODE_FLUSH_AFTER_CONFIG: This mode is used to flush any buffered messages when the LOG_MODE_BUFFER_BEFORE_CONFIG declaration is specified in the declaration of the logger.
The file parameter specifies the filename that should be used to log messages. This parameter may be NULL if LOG_MODE_OUTPUT_FILE is not specified.
The facility parameter is the syslog facility that should be used when logging
messages.
+LOG_MODE_NOSUBSYS: Enabling this mode removes the subsystem tag from the beginning of the log lines. This is not recommended for programs which have multiple subsystems.
-An example declartion would be:
+An example declaration would be:
#include
@@ -90,7 +92,7 @@
This would output any logging messages to stderr, syslog, and the file /tmp/log.
-.SH Declartion of subsystems or no subsystems
+.SH Declaration of subsystems or no subsystems
The logsys library supports the logging of information to one main system or
subsystem. This is specified in each individual object file in the system.
@@ -113,7 +115,7 @@
LOGSYS_DECLARE_SUBSYS ("SYS1", LOG_LEVEL_INFO);
Any message of LOG_LEVEL_INFO priority or higher would be logged and any
-logging within the object file this declartion is specified within will be
+logging within the object file this declaration is specified within will be
logged to the SYS1 subsystem identifier.
.SH Logging Messages
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] TRUNK patch - Allow shortened file/line output from logsys.c
On Tue, 2008-07-01 at 15:34 -0700, Steven Dake wrote: > one other note on this patch - could you make a separate patch for > logsys_overview.8 to include the new modes? Yes, I'll do that today. -- Lon ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] logsys patch
On Tue, 2008-07-01 at 14:32 -0500, David Teigland wrote: > The attached patch adds a simple, function-based api to logsys, allowing > simple programs to use it more cleanly (without macros). I'd like to see this included as well; single-subsystem utilities (such as fence agents) would certainly benefit from a simplified API like this, particularly if we want to log from multiple files without redefining the same thing in each file. With this extension, if I understand it correctly, we also do not need to change every file in the tree if we want to change our default log level for a single-subsys piece of software. (Even if we don't now, it would look mighty strange to have mismatched LOGSYS_DECLARE_SUBSYS() lines all over the place). Unfortunately, it appears to rely on my patch (LOGSYS_MODE_NOSUBSYS) which has not been incorporated nor rejected at this point. If my patch is rejected, we will need to fix a little bit of code. -- Lon ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] TRUNK patch - Allow shortened file/line output from logsys.c
On Fri, 2008-06-27 at 15:33 -0400, Lon Hohberger wrote:
> If you add LOG_MODE_SHORT_FILELINE, it changes the the following debug
> line from:
>
> [/sandbox/lhh/cluster/fence/agents/xvm/fence_xvmd.c:0587] My Node ID = 1
>
> ...to:
>
> [fence_xvmd.c:0587] My Node ID = 1
>
> Most developers who insert LOG_DEBUG lines will be able to determine out
> of context which source code file a particular log message came from, so
> it is arguable the entire path spec is unnecessary (and perhaps
> "SHORT_FILELINE" should be the default; but we'll leave that for another
> day).
This patch supplants the previous one and adds support for setting
"nosubsys" as a mode flag instead of its own global variable (which
can't currently be unset).
-- Lon
Index: logsys.c
===
--- logsys.c (revision 1568)
+++ logsys.c (working copy)
@@ -69,8 +69,6 @@
static int logsys_facility = LOG_DAEMON;
-static int logsys_nosubsys = 0;
-
static int logsys_wthread_active = 0;
static pthread_mutex_t logsys_config_mutex = PTHREAD_MUTEX_INITIALIZER;
@@ -121,7 +119,7 @@
void _logsys_nosubsys_set (void)
{
- logsys_nosubsys = 1;
+ logsys_mode |= LOG_MODE_NOSUBSYS;
}
int logsys_facility_id_get (const char *name)
@@ -298,6 +296,7 @@
char newstring[4096];
char log_string[4096];
char char_time[512];
+ char *p = NULL;
struct timeval tv;
int i = 0;
int len;
@@ -331,9 +330,14 @@
}
if ((priority == LOG_LEVEL_DEBUG) || (logsys_mode & LOG_MODE_DISPLAY_FILELINE)) {
+ if (logsys_mode & LOG_MODE_SHORT_FILELINE) {
+ p = strrchr(file, '/');
+ if (p)
+file = ++p;
+ }
sprintf (&newstring[i], "[%s:%04u] %s", file, line, format);
} else {
- if (logsys_nosubsys == 1) {
+ if (logsys_mode & LOG_MODE_NOSUBSYS) {
sprintf (&newstring[i], "%s", format);
} else {
sprintf (&newstring[i], "[%-5s] %s", logsys_loggers[id].subsys, format);
Index: logsys.h
===
--- logsys.h (revision 1568)
+++ logsys.h (working copy)
@@ -52,6 +52,8 @@
#define LOG_MODE_DISPLAY_TIMESTAMP (1<<7)
#define LOG_MODE_BUFFER_BEFORE_CONFIG (1<<8)
#define LOG_MODE_FLUSH_AFTER_CONFIG (1<<9)
+#define LOG_MODE_SHORT_FILELINE (1<<10)
+#define LOG_MODE_NOSUBSYS (1<<11)
/*
* Log priorities, compliant with syslog and SA Forum Log spec.
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
[Openais] TRUNK patch - Allow shortened file/line output from logsys.c
If you add LOG_MODE_SHORT_FILELINE, it changes the the following debug
line from:
[/sandbox/lhh/cluster/fence/agents/xvm/fence_xvmd.c:0587] My Node ID = 1
...to:
[fence_xvmd.c:0587] My Node ID = 1
Most developers who insert LOG_DEBUG lines will be able to determine out
of context which source code file a particular log message came from, so
it is arguable the entire path spec is unnecessary (and perhaps
"SHORT_FILELINE" should be the default; but we'll leave that for another
day).
-- Lon
Index: exec/logsys.c
===
--- exec/logsys.c (revision 1568)
+++ exec/logsys.c (working copy)
@@ -298,6 +298,7 @@
char newstring[4096];
char log_string[4096];
char char_time[512];
+ char *p = NULL;
struct timeval tv;
int i = 0;
int len;
@@ -331,6 +332,11 @@
}
if ((priority == LOG_LEVEL_DEBUG) || (logsys_mode & LOG_MODE_DISPLAY_FILELINE)) {
+ if (logsys_mode & LOG_MODE_SHORT_FILELINE) {
+ p = strrchr(file, '/');
+ if (p)
+file = ++p;
+ }
sprintf (&newstring[i], "[%s:%04u] %s", file, line, format);
} else {
if (logsys_nosubsys == 1) {
Index: exec/logsys.h
===
--- exec/logsys.h (revision 1568)
+++ exec/logsys.h (working copy)
@@ -52,6 +52,7 @@
#define LOG_MODE_DISPLAY_TIMESTAMP (1<<7)
#define LOG_MODE_BUFFER_BEFORE_CONFIG (1<<8)
#define LOG_MODE_FLUSH_AFTER_CONFIG (1<<9)
+#define LOG_MODE_SHORT_FILELINE (1<<10)
/*
* Log priorities, compliant with syslog and SA Forum Log spec.
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] logsys issues with fork [PATCH]
On Wed, 2008-04-16 at 14:15 -0400, Lon Hohberger wrote:
Actually attach it ;)
-- Lon
Index: test/Makefile
===
--- test/Makefile (revision 1516)
+++ test/Makefile (working copy)
@@ -161,13 +161,13 @@
$(CC) $(LDFLAGS) -o openais-cfgtool openais-cfgtool.o $(LIBS)
logsys_s: logsys_s.o logsys_s1.o logsys_s2.o ../exec/liblogsys.a
- $(CC) $(LDFLAGS) -o logsys_s logsys_s.o logsys_s1.o logsys_s2.o ../exec/liblogsys.a
+ $(CC) $(LDFLAGS) -o logsys_s logsys_s.o logsys_s1.o logsys_s2.o ../exec/liblogsys.a -lpthread
logsys_t1: logsys_t1.o ../exec/liblogsys.a
- $(CC) $(LDFLAGS) -o logsys_t1 logsys_t1.o ../exec/liblogsys.a
+ $(CC) $(LDFLAGS) -o logsys_t1 logsys_t1.o ../exec/liblogsys.a -lpthread
logsys_t2: logsys_t2.o ../exec/liblogsys.a
- $(CC) $(LDFLAGS) -o logsys_t2 logsys_t2.o ../exec/liblogsys.a
+ $(CC) $(LDFLAGS) -o logsys_t2 logsys_t2.o ../exec/liblogsys.a -lpthread
clean:
rm -f *.o $(LIBRARIES) $(BINARIES)
Index: exec/Makefile
===
--- exec/Makefile (revision 1516)
+++ exec/Makefile (working copy)
@@ -175,7 +175,7 @@
endif
aisexec: $(EXEC_OBJS) $(EXEC_LIBS)
- $(CC) $(LDFLAGS) $(EXEC_OBJS) $(EXEC_LIBS) -o aisexec
+ $(CC) $(LDFLAGS) $(EXEC_OBJS) $(EXEC_LIBS) -o aisexec -lpthread
libtotem_pg.a: $(TOTEM_OBJS)
$(AR) -rc libtotem_pg.a $(TOTEM_OBJS)
Index: exec/logsys.c
===
--- exec/logsys.c (revision 1516)
+++ exec/logsys.c (working copy)
@@ -255,7 +255,8 @@
{
struct log_data *log_data = (struct log_data *)work_item;
- pthread_mutex_lock (&logsys_config_mutex);
+ if (logsys_wthread_active)
+ pthread_mutex_lock (&logsys_config_mutex);
/*
* Output the log data
*/
@@ -273,7 +274,8 @@
&log_data->log_string[log_data->syslog_pos]);
}
free (log_data->log_string);
- pthread_mutex_unlock (&logsys_config_mutex);
+ if (logsys_wthread_active)
+ pthread_mutex_unlock (&logsys_config_mutex);
}
static void _log_printf (
@@ -467,6 +469,14 @@
pthread_mutex_unlock (&logsys_new_log_mutex);
}
+static void child_cleanup (void)
+{
+ memset(&log_thread_group, 0, sizeof(log_thread_group));
+ logsys_wthread_active = 0;
+ pthread_mutex_init(&logsys_config_mutex, NULL);
+ pthread_mutex_init(&logsys_new_log_mutex, NULL);
+}
+
int _logsys_wthread_create (void)
{
worker_thread_group_init (
@@ -481,6 +491,7 @@
logsys_flush();
atexit (logsys_atexit);
+ pthread_atfork(NULL, NULL, child_cleanup);
if (logsys_mode & LOG_MODE_OUTPUT_SYSLOG_THREADED && logsys_name != NULL) {
openlog (logsys_name, LOG_CONS|LOG_PID, logsys_facility);
Index: Makefile.inc
===
--- Makefile.inc (revision 1516)
+++ Makefile.inc (working copy)
@@ -45,7 +45,7 @@
# default CFLAGS, LDFLAGS
#
-CFLAGS =
+CFLAGS = -g
LDFLAGS =
DYFLAGS =
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] logsys issues with fork [PATCH]
Hi Fabio, I'd call this a 'pass 1' patch. * This makes your test program work. * This does not cause a regression with the existing logsys test cases in the openais trunk. It, however, dirties up the build system because it requires changing the linking order (logsys now needs -lpthread after it. For some reason, it didn't before (despite using other pthread APIs); someone probably knows why - as well as the correct way to fix it within the context of the openais build system. It would be *potentially* cleaner to make the child "cleanup" function an explicitly-called function, but probably less nice from a user API perspective. Basically, pthread_atfork() makes it a pretty simple thing since the user doesn't need to do anything in the child process (I think pthread_atfork was primarily designed for use in threaded APIs, anyway). Minimally, we needed to zap the mutexes and the thread indicators (since there's no threads in the child process... yet). Upon further investigation, I noticed a double-lock when doing _log_printf around the config mutex (_log_printf does a lock and so does log_printf_worker_fn, causing the child to hang on itself). To remedy this, I added a check for logsys_wthread_active (which will be 0 in the child process unless a full reinitialization is done) - but I'm not sure if this is the right thing to do or not. -- Lon ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] logsys issues with fork
On Fri, 2008-04-04 at 14:45 +0200, Fabio M. Di Nitto wrote: > On Fri, 4 Apr 2008, Lon Hohberger wrote: > > > > > On Fri, 2008-04-04 at 14:29 +0200, Fabio M. Di Nitto wrote: > >> Hi Lon and Steven, > >> > >> i found a bug in liblogsys and i have no idea how to fix it. > >> > >> In attachment there is the smallest test case i could write. > >> > >> Build with: gcc -Wall -O0 -ggdb test.c -L/usr/lib/openais -llogsys > >> or similar.. please keep liblogsys shared as it should be in the final > >> application. > >> > >> The problem is that logsys init doesn't survive a fork() used to daemonize > >> (like many applications do). > > > > pthread_atfork needed? > > where? seriously.. this thing is giving me headache So - basically, my thought was that fork() shouldn't suddenly break stuff. I haven't looked at the logsys lib in awhile, but generally speaking, libraries which use threading models to accomplish stuff usually need some immediate reinitialization after fork() in the child process. One solution is to register a pthread_atfork() for the child side of the fork to respawn the logging thread in the child process and reinitialize any mutexes which are there. Forking with the mutex held by another thread would result in a hang in the child process, obviously, because the mutex state would be copied. The problem with registering an atfork handler is that if you use it incorrectly, you could leak memory. pthread_atfork doesn't cancel registrations after a fork nor does fork() free the memory allocated by a pthread_atfork() registration. Another option would be to have log_printf() watch PIDs and if the PID changes, reinit the subsystem (thread(s), mutex(es)) for the user transparently. A third option would be to have the user call something simple to do this work in the child process, though this is the least transparent at the API level (and is a bit annoying), but it's also very clean - particularly if the child process doesn't actually need to use liblogsys due to an immediate exec() afterwards. I can look at liblogsys and propose something, but I can't do it for a few days. -- Lon ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] logsys issues with fork
On Fri, 2008-04-04 at 14:29 +0200, Fabio M. Di Nitto wrote: > Hi Lon and Steven, > > i found a bug in liblogsys and i have no idea how to fix it. > > In attachment there is the smallest test case i could write. > > Build with: gcc -Wall -O0 -ggdb test.c -L/usr/lib/openais -llogsys > or similar.. please keep liblogsys shared as it should be in the final > application. > > The problem is that logsys init doesn't survive a fork() used to daemonize > (like many applications do). pthread_atfork needed? -- Lon ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] xml api with no handle - and tracking integrated into track function
Hi Steve, I don't know where the handle management went (but I don't *think* I'm going to miss it). I probably missed some part of that discussion somewhere, just like I missed part of the v.2 API that specified the sync API ;) However, for my purposes, this API is sufficient, given that Fabio's XPath use cases was a complete set. It looks easy to use, it provides sync & async APIs, and provides list & single-query APIs. In talking with Dave, there might be some other things to think about. -- Lon ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] new config system
On Wed, 2008-03-26 at 10:32 -0500, David Teigland wrote: > > [1] Just to be clear, the meta-configuration idea is where a variety of > config files can be used to populate a central config-file-agnostic > respository. A single interface is used by all to read config data from > the repository. Even if we did this, I don't see what it would give us > anything. All our existing applications access data that's only specified > in a single config file anyway, so interchangable back-end files would be > an unused feature. True, it doesn't give _us_ much to be agnostic to what the config file format looks like. However, with different back-ends used to populate the single config repo at run-time, we then have the ability to not have config files at all (well, except the meta-config stuff). What I mean is: An administrator might like to store the cluster configuration in an inventory database which isn't local to the cluster itself (e.g. LDAP, or whatever). This might not be a requirement now, but that was one of the points of having multiple config back-ends, IIRC. I guess there's no reason that we couldn't cache a local copy of the configuration... *shrug* -- Lon ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] A tale of Two Developers, or, On Configuration API
On Mon, 2008-03-24 at 16:36 -0700, Joel Becker wrote:
> [Joel]
> Enough with the third person. I see no reason these API cannot
> coexist. In fact, they are just layers atop each other. While there is
> a question of who implements which layer, I think we've settled that a
> core library should present them so that we can drop extrinsic
> libraries like libcman (which is doing the API for Fabio right now).
> What does everyone think? Did I capture the ways we are seeing
> objdb access?
Note that Fabio's libcman/ccs API is effectively a subset of XPath[1] as
is used today by CMAN and friends to run down an XML tree. CCS was just
a daemon which wraps around XPath in a distributed fashion, which we can
do from libcman now.
I don't know the internals of the asynchronous API, but it looks pretty
cumbersome to use with a tree structured configuration if the structure
of the tree itself is dynamic.
With a sync API, you can build your queries as you go:
get_config_attributes_recursive(key, node) {
while(has_children(node)) {
child = get_next_child(key + "/child::*");
if (child) {
get_config_attributes_recursive(
key + "/" + child->name,
child);
}
}
if (node->type == "foo") {
get_foo_attributes(key, node, "foo");
} else if (node->type == "bar") {
get_bar_attributes(key, node, "bar");
} ...
}
In the case of rgmanager[2] (which currently uses CCS), this happens
frequently enough that it's interesting; admins can craft services in
any structure they want.
For example, a node might have its parent deleted, which would affect
how that node's values are interpreted, and what keys identify that
node's attributes/values:
foo{
name: temp
bar{
name: bar1
baz{
name: test
value1: one
value2: two
}
}
}
... might become:
foo{
name: temp
baz{
name: test
value1: one
value2: two
}
bar{
name: bar1
}
}
Baz went from being bar's child to being its sibling. However, no
values of baz have changed.
Currently, we key off one value in the configuration (which has a
statically-defined location in the configuration). When that value
changes (ex: delivered by an async callback[3]), we traverse the new
configuration tree in synchronous fashion, learning the new structure of
the configuration as we go.
-- Lon
[1] http://www.w3.org/TR/xpath
[2] Pacemaker will also run into this if it ends up using openais for
configuration data at some point, I suspect (currently it rolls its own
which is just XML)
[3] CCS doesn't have a callback, but we wish it did for this purpose :(
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
[Openais] [PATCH] aisexec_tty_detach call setsid() & map standard I/O to /dev/null
Benefits:
* Calling setsid() creates a new process group, which is probably
something you actually want with aisexec.
* Mapping 0/1/2 to /dev/null prevents printfs in the code from causing
problems (even if they're not "supposed" to be there). For example, if
code at some point calls printf() - but file descriptor 1 is an IPC file
descriptor - bad things happen, I suspect.
Notes:
While POSIX defines /dev/null to exist and be a character device, a more
complete patch would check for those properties.
setsid() should probably have its return code checked, but I'm not sure
if doing so would upset things; does it matter (since openais doesn't
call setsid() now) if it fails?
-- Lon
Index: exec/main.c
===
--- exec/main.c (revision 1480)
+++ exec/main.c (working copy)
@@ -280,7 +280,7 @@
static void aisexec_tty_detach (void)
{
- int lpc;
+ int lpc, fd;
struct rlimit oflimits;
/*
@@ -307,6 +307,24 @@
exit (0);
break;
}
+
+ /* Create new session */
+ setsid();
+
+ /*
+ * Map stdin/out/err to /dev/null.
+ */
+ fd = open("/dev/null", O_RDWR);
+ if (fd >= 0) {
+ /* dup2 to 0 / 1 / 2 (stdin / stdout / stderr) */
+ dup2(fd, STDIN_FILENO); /* 0 */
+ dup2(fd, STDOUT_FILENO); /* 1 */
+ dup2(fd, STDERR_FILENO); /* 2 */
+
+ /* Should be 0, but just in case it isn't... */
+ if (fd > 2)
+ close(fd);
+ }
}
static void aisexec_setscheduler (void)
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
