[irc.git] / software / RELEASES / ircservices / achurch.org / services / lists / ircservices / 2001 / 002639.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [IRCServices] Log Rotation and -SIGUSR2
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Log%20Rotation%20and%20-SIGUSR2&In-Reply-To=3c18b979.67513%40achurch.org">
   <META NAME="robots" CONTENT="index,nofollow">
   <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
   <LINK REL="Previous"  HREF="002637.html">
   <LINK REL="Next"  HREF="002638.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[IRCServices] Log Rotation and -SIGUSR2</H1>
    <B>Mark Hetherington</B> 
    <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Log%20Rotation%20and%20-SIGUSR2&In-Reply-To=3c18b979.67513%40achurch.org"
       TITLE="[IRCServices] Log Rotation and -SIGUSR2">mark at mhetherington.demon.co.uk
       </A><BR>
    <I>Fri Dec 14 03:15:03 PST 2001</I>
    <P><UL>
        <LI>Previous message: <A HREF="002637.html">[IRCServices] Version 5.0 alpha release available
</A></li>
        <LI>Next message: <A HREF="002638.html">[IRCServices] killclones
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#2639">[ date ]</a>
              <a href="thread.html#2639">[ thread ]</a>
              <a href="subject.html#2639">[ subject ]</a>
              <a href="author.html#2639">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>I was not a subscriber to the list at the time the rotate_log() function was
removed so missed the discussion. I haven't yet come across it in the
archives. For these reasons, some of what I say here may have come up
before.

kill -SIGUSR2 combined with a move of the log file does not seem to be the
best manner in which to manage the log rotation, at least IME. Quite often,
the sequence will result in services performing an SQUIT with an error
message of:

Read error from server: Success

to it's log file.

So far I have been unable to discover the exact reason what services thinks
is an error especially given the lack of error indicated with the error
message.

Various combinations of file operations and the SIGUSR signal have been
tried with no noticable change.

So far I have been unable through existing debug code been able to ascertain
the exact cause of the problem however I suspect that it is a timing issue
with services responding to the signal at the wrong point during the file
system operations (maybe the file operation is still in progress, maybe file
size has some effect on this).

Since the problem is only semi-regularly reproducable on the production
network, I am limited as to how often I can debug the problem and I suspect
that I would be better placed merely rewriting the log/signal processing to
use a system that would not suffer these problems. Sometimes services will
run for a couple months without a problem then other times it will have the
problem every day. Again this is not helpful for attempting to debug the
cause.

Having had a quick look at the source code for Services 5 alpha, it seems
the SIGUSR2/logging code is almost identical so this will likely remain an
issue with newer versions of services.

Although I would be interested in hearing other's experience and techniques
for managing log rotation, I do have a couple of suggestions that I believe
would be useful to have in the main build of services:

1) Restore the original rotate_log() function or provide a new one - using a
compile time #define would mean that those that do no want to have the code
compiled in do not have to. Yes I can provide my own rotate_log() code, but
with Services 5 coming up and the likely need for more frequent upgrades in
the early days, I would prefer not to have to keep patching the log code.

2) Alter the log naming convention so that it becomes LogFileName.suffix
where suffix is generated from the current date. eg 20011213. This would
allow the existing SIGUSR2 code to actually produce dated log files in a
similar way to eggdrop and some IRCd software does in their own rotate log
functions while making the whole system somewaht less susceptable to any
other issues. Using eggdrop as an example, it is again a simple
configuration item to have this system optional for any users of services
that do not use daily logs.

3) The error system needs some improvement. &quot;Read error from server:
Success&quot; is not a useful error message. The nature of the error needs
reporting.


Should I manage to extract any further information as to the cause of the
problem, I will notify the group, but after months of this issue occurring
on and off with only once a date testing facilities, it does seem far easier
to merely rewrite the code that is causing the problem.

Mark.


</PRE>

<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="002637.html">[IRCServices] Version 5.0 alpha release available
</A></li>
	<LI>Next message: <A HREF="002638.html">[IRCServices] killclones
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#2639">[ date ]</a>
              <a href="thread.html#2639">[ thread ]</a>
              <a href="subject.html#2639">[ subject ]</a>
              <a href="author.html#2639">[ author ]</a>
         </LI>
       </UL>

</body></html>
Commit	Line	Data
3bd189cb JR	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
	2	<HTML>
	3	<HEAD>
	4	<TITLE> [IRCServices] Log Rotation and -SIGUSR2
	5	</TITLE>
	6	<LINK REL="Index" HREF="index.html" >
	7	<LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Log%20Rotation%20and%20-SIGUSR2&In-Reply-To=3c18b979.67513%40achurch.org">
	8	<META NAME="robots" CONTENT="index,nofollow">
	9	<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
	10	<LINK REL="Previous" HREF="002637.html">
	11	<LINK REL="Next" HREF="002638.html">
	12	</HEAD>
	13	<BODY BGCOLOR="#ffffff">
	14	<H1>[IRCServices] Log Rotation and -SIGUSR2</H1>
	15	<B>Mark Hetherington</B>
	16	<A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Log%20Rotation%20and%20-SIGUSR2&In-Reply-To=3c18b979.67513%40achurch.org"
	17	TITLE="[IRCServices] Log Rotation and -SIGUSR2">mark at mhetherington.demon.co.uk
	18	</A><BR>
	19	<I>Fri Dec 14 03:15:03 PST 2001</I>
	20	<P><UL>
	21	<LI>Previous message: <A HREF="002637.html">[IRCServices] Version 5.0 alpha release available
	22	</A></li>
	23	<LI>Next message: <A HREF="002638.html">[IRCServices] killclones
	24	</A></li>
	25	<LI> <B>Messages sorted by:</B>
	26	<a href="date.html#2639">[ date ]</a>
	27	<a href="thread.html#2639">[ thread ]</a>
	28	<a href="subject.html#2639">[ subject ]</a>
	29	<a href="author.html#2639">[ author ]</a>
	30	</LI>
	31	</UL>
	32	<HR>
	33	<!--beginarticle-->
	34	<PRE>I was not a subscriber to the list at the time the rotate_log() function was
	35	removed so missed the discussion. I haven't yet come across it in the
	36	archives. For these reasons, some of what I say here may have come up
	37	before.
	38
	39	kill -SIGUSR2 combined with a move of the log file does not seem to be the
	40	best manner in which to manage the log rotation, at least IME. Quite often,
	41	the sequence will result in services performing an SQUIT with an error
	42	message of:
	43
	44	Read error from server: Success
	45
	46	to it's log file.
	47
	48	So far I have been unable to discover the exact reason what services thinks
	49	is an error especially given the lack of error indicated with the error
	50	message.
	51
	52	Various combinations of file operations and the SIGUSR signal have been
	53	tried with no noticable change.
	54
	55	So far I have been unable through existing debug code been able to ascertain
	56	the exact cause of the problem however I suspect that it is a timing issue
	57	with services responding to the signal at the wrong point during the file
	58	system operations (maybe the file operation is still in progress, maybe file
	59	size has some effect on this).
	60
	61	Since the problem is only semi-regularly reproducable on the production
	62	network, I am limited as to how often I can debug the problem and I suspect
	63	that I would be better placed merely rewriting the log/signal processing to
	64	use a system that would not suffer these problems. Sometimes services will
65	run for a couple months without a problem then other times it will have the
66	problem every day. Again this is not helpful for attempting to debug the
67	cause.
68
69	Having had a quick look at the source code for Services 5 alpha, it seems
70	the SIGUSR2/logging code is almost identical so this will likely remain an
71	issue with newer versions of services.
72
73	Although I would be interested in hearing other's experience and techniques
74	for managing log rotation, I do have a couple of suggestions that I believe
75	would be useful to have in the main build of services:
76
77	1) Restore the original rotate_log() function or provide a new one - using a
78	compile time #define would mean that those that do no want to have the code
79	compiled in do not have to. Yes I can provide my own rotate_log() code, but
80	with Services 5 coming up and the likely need for more frequent upgrades in
81	the early days, I would prefer not to have to keep patching the log code.
82
83	2) Alter the log naming convention so that it becomes LogFileName.suffix
84	where suffix is generated from the current date. eg 20011213. This would
85	allow the existing SIGUSR2 code to actually produce dated log files in a
86	similar way to eggdrop and some IRCd software does in their own rotate log
87	functions while making the whole system somewaht less susceptable to any
88	other issues. Using eggdrop as an example, it is again a simple
89	configuration item to have this system optional for any users of services
90	that do not use daily logs.
91
92	3) The error system needs some improvement. "Read error from server:
93	Success" is not a useful error message. The nature of the error needs
94	reporting.
95
96
97	Should I manage to extract any further information as to the cause of the
98	problem, I will notify the group, but after months of this issue occurring
99	on and off with only once a date testing facilities, it does seem far easier
100	to merely rewrite the code that is causing the problem.
101
102	Mark.
103
104
105	</PRE>
106
107	<!--endarticle-->
108	<HR>
109	<P><UL>
110	<!--threads-->
111	<LI>Previous message: <A HREF="002637.html">[IRCServices] Version 5.0 alpha release available
112	</A></li>
113	<LI>Next message: <A HREF="002638.html">[IRCServices] killclones
114	</A></li>
115	<LI> <B>Messages sorted by:</B>
116	<a href="date.html#2639">[ date ]</a>
117	<a href="thread.html#2639">[ thread ]</a>
118	<a href="subject.html#2639">[ subject ]</a>
119	<a href="author.html#2639">[ author ]</a>
120	</LI>
121	</UL>
122
123	</body></html>