Maybe a bit odd since only <10 things use this category but it makes it
stand out as a separate thing much better. As for a level (not that it
matters) it is between 'info' and 'warn'.
In debug mode we also - in the JSON log - log the source file and
line number in every log message. This requires special care. A good
start was made earlier but that fix was incorrect.
Should be good now... at least when i ran tests the leak that was
previously there was gone.
The original issue was that I used (again, only in DEBUGMODE):
#define unreal_log(...) do_unreal_log(__VA_ARGS__, log_data_source(__FILE__, __LINE__, __FUNCTION__), NULL)
But, some functions call unreal_log with something like:
unreal_log(.....
xyz ? log_data_client("xyz", xyz) : NULL);
And then the expanded function arguments may become:
NULL,
log_data_source(...)
And since it is a vararg list the first NULL already terminates it and the
log_data_source() is never iterated, stays unseen, and thus stays unfreed.
A fix for that was made in 42caa34b5c:
do {
LogData *lds = log_data_source(__FILE__, __LINE__, __FUNCTION__);
do_unreal_log(__VA_ARGS__, lds, NULL); log_data_free(lds);
} while(0)
but in practice we still freed at the wrong place... it was still being
freed in the do_unreal_log() (or a child) function and the log_data_free()
actually didn't free anything.
All that is now fixed in this commit.
This way things like the TOPIC will keep their color codes if they have it.
Reported by armyn in https://bugs.unrealircd.org/view.php?id=6259
(And yeah i used a global to achieve this, otherwise it has too much
of a cascading effect in XYZ functions)
This also changes the Detail level (object_detail_level) for the channel.* calls.
See https://www.unrealircd.org/docs/JSON-RPC:Channel_Object for latest info.
In short: at level 5, we now still hide the members.user.channels because
in general that object is not useful. When you do a channel.* API call
you want a list of users in the channel, and don't really care about
what other channels the user is in, other than the channel you already know.
This is an integer which decides the amount of details in the response object.
For the channel.* calls the object_detail_level is one of:
0: only return the channel name, nothing else
1: basic channel information only
2: this adds bans, ban_exemptions, invite_exceptions
3: also show members, but only level/name/id
4: also show members, level/name/id/hostname/ip/details/geoip
5: also show members, level and full user details like user.get
When no object_detail_level is specified, the following defaults are used:
For channel.list the default is 1 (matches current 6.0.6 behavior)
For channel.get the default is 3 (matches current 6.0.6 behavior)
Using channel.list with object_detail_level=5 is forbidden because
it would cause way too much output (and processing time).
if you do actually have 1 snomask configured (a single one).
Although this is rather rare and unusual, it should be possible.
Previously we required at least 2 snomasks and the counter
did not properly reset during rehashes. Not sure why we required
2 and not 1, and the counter reset was a bug.
Reported by westor in https://bugs.unrealircd.org/view.php?id=5994
since these are rather noisy and generally not very interesting to log.
Of course, DO log them if they are like add/delete/etc.
The way this works is a new property in the RPCHandler, eg:
memset(&r, 0, sizeof(r));
r.method = "server.list";
+ r.loglevel = ULOG_DEBUG;
r.call = rpc_server_list;
if (!RPCHandlerAdd(modinfo->handle, &r))
All of the .list and .get (and things like .module_list) now use
the debug facility, which is not logged by default.
You can still log ALL the JSON-RPC calls if you wish, for example
to a separate file, through something like:
log {
source { rpc; }
destination {
file "rpc.log" { maxsize 100M; }
}
}
RPC clients with the RPC user and such.
Most of this work is for server.rehash which causes the request to
be saved, then a rehash begins, and a few seconds later (or whenever)
the entire rehash log and success/failure is indicated in the
JSON-RPC response.
TODO: all documentation for this
You could already have something like:
log { source { !debug; all; } destination { file "ircd.%Y-%m-%d.log"; } }
But now you can also have:
log { source { !debug; all; } destination { file "%Y-%m-%d/ircd.log"; } }
This is especially useful if you output to multiple log files and then
want them grouped by date in a directory.
The list of channels (which is an array) is limited to a total
of 384 characters after JSON expansion. If it is limited then
the last item will be "...".
Suggested by westor in https://bugs.unrealircd.org/view.php?id=6083
The "vhost" field is added if the visible host of the user differs
from the real hostname, such as +x with cloaking or +xt with a vhost.
The "cloakedhost" is always included, even if the user does not
currently have a cloaked host at all (eg is -x or using a vhost).
Both make it easier to search log files based on user reports.
Eg a user mentions a vhost or cloaked host from their user logs
and then a server admin searches the UnrealIRCd logs on this to
retrieve the real host / ip / user based on that.
clients etc. are expanded in the logging routines.
HOOKTYPE_JSON_EXPAND_CLIENT - for all clients
HOOKTYPE_JSON_EXPAND_CLIENT_USER - for clients that are users
HOOKTYPE_JSON_EXPAND_CLIENT_SERVER - for clients that are servers
HOOKTYPE_JSON_EXPAND_CHANNEL - for channels
on each string. Note that the entire JSON dump may still be much larger,
this is just about each individual string item within an object.
This commit also adds a more flexible StripControlCodesEx() function
to the core (which is used by the logging system), the existing
StripControlCodes() function is unchanged and can still be used.
+/** Strip color, bold, underline, and reverse codes from a string.
+ * @param text The input text
+ * @param output The buffer for the output text
+ * @param outputlen The length of the output buffer
+ * @param strip_all_low_ascii If set to 1 then all ASCII < 32 is stripped
+ * (the ASCII control codes), otherwise we only
+ * strip the IRC control- and color codes.
+ * @returns The new string, which will be 'output', or in unusual cases (outputlen==0) will be NULL.
+ */
+const char *StripControlCodesEx(const char *text, char *output, size_t outputlen, int strip_all_low_ascii)
{
the server name. Nowadays we receive and log lines from remote servers
so without this extra information it can be unclear where events
(eg: problems) are happening which can be rather confusing.
"./unrealircd reloadtls" and there is now also a "./unrealircd status"
The output is colorized if the terminal supports it (just like on the
boot screen) and also the exit status is 0 for success and non-0 for
failure. The purpose of all this is that you can easily detect rehash
errors on the command line.
These three commands communicate to UnrealIRCd via the new control
UNIX socket, which is in ~/data/unrealircd.ctl.
This also does a lot of other stuff because we now have an internal
tool called bin/unrealircdctl which is called by ./unrealircd for
some of the commands to communicate to the unrealircd.ctl socket.
Later on more of the existing functionality may be moved to that
tool and we may also provide it on Windows in CLI mode so people
have more of the same functionality as on *NIX.
the [expires: ZZZZZZZZZZZZZZZZZZZZ GMT] string.
This because most people are interested in the length of the ban (so
relative time) and the exact time a TKL expires is less interesting
(the absolute time) and due to GMT/UTC requires calculating to the
local timezone too.
This also makes the tkl expiry messages be more like the add message,
with []'s, while previous it used more free text at the end of the line.
Bram Matthys