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