1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
/* $Id: log.h,v 1.7 2001-08-26 21:10:04 rjkaes Exp $
*
* See 'log.c' for a detailed description.
*
* Copyright (C) 1998 Steven Young
* Copyright (C) 1999 Robert James Kaes (rjkaes@flarenet.com)
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2, or (at your option) any
* later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*/
#ifndef TINYPROXY_LOG_H
#define TINYPROXY_LOG_H
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
/*
* Okay, I have modelled the levels for logging off the syslog() interface.
* However, I would really prefer if only five of the levels are used. You
* can see them below and I'll describe what each level should be for.
* Hopefully tinyproxy will remain consistent with these levels.
* -- rjkaes
* Sorry but I had to destroy the hope ;-) There was a need to log
* connections without the INFO stuff and not to have them as NOTICE.
* -- hgb
*
* Level Description
* ----- -----------
* LOG_CRIT This is catastrophic. Basically, tinyproxy can not recover
* from this and will either close the thread (if we're lucky),
* or the entire daemon. I would relegate this to conditions
* like unable to create the listening socket, or unable to
* create a thread. If you're going to log at this level provide
* as much information as possible.
*
* LOG_ERR Okay, something bad happened. We can recover from this, but
* the connection will be terminated. This should be for things
* like when we cannot create a socket, or out of memory.
* Basically, the connection will not work, but it's not enough
* to bring the whole daemon down.
*
* LOG_WARNING There is condition which will change the behaviour of
* tinyproxy from what is expected. For example, somebody did
* not specify a port. tinyproxy will handle this (by using
* it's default port), but it's a _higher_ level situation
* which the admin should be aware of.
*
* LOG_NOTICE This is for a special condition. Nothing has gone wrong, but
* it is more important than the common LOG_INFO level. Right
* now it is used for actions like creating/destroying threads,
* unauthorized access, signal handling, etc.
*
* LOG_CONN This additional level is for logging connections only, so
* it is easy to control only the requests in the logfile.
* If we log through syslog, this is set to LOG_INFO.
* -- hgb
*
* LOG_INFO Everything else ends up here. Logging for incoming
* connections, denying due to filtering rules, unable to
* connect to remote server, etc.
*
* LOG_DEBUG Don't use this level. :) Use the two DEBUG?() macros
* instead since they can remain in the source if needed. (I
* don't advocate this, but it could be useful at times.)
*/
#ifdef HAVE_SYSLOG_H
# include <syslog.h>
#else
# define LOG_CRIT 2
# define LOG_ERR 3
# define LOG_WARNING 4
# define LOG_NOTICE 5
# define LOG_INFO 6
# define LOG_DEBUG 7
#endif
#define LOG_CONN 8 /* extra to log connections without the INFO stuff */
/*
* Use this for debugging. The format is specific:
* DEBUG1("There was a major problem");
* DEBUG2("There was a big problem: %s in connptr %p", "hello", connptr);
*/
#ifndef NDEBUG
# define DEBUG1(x) log_message(LOG_DEBUG, "[%s:%d] " x, __FILE__, __LINE__)
# define DEBUG2(x, y...) log_message(LOG_DEBUG, "[%s:%d] " x, __FILE__, __LINE__, ## y)
#else
# define DEBUG1(x) do { } while(0)
# define DEBUG2(x, y...) do { } while(0)
#endif
extern void log_message(short int level, char *fmt, ...);
extern void set_log_level(short int level);
#endif
|
