IRC Services Manual
Appendix D. Known issues
Table of Contents
There are a few issues which have been reported as bugs in the past or
discovered by the author, but which either are not consistently
reproduceable or are a consequence of the way Services works and not easily
avoidable:
- Services appears to incorrectly detect "mode bouncing" (i.e.,
the IRC server reversing Services' mode changes) in some cases. When this
occurs, commands like KICK and TOPIC as well as auto-ops
and mode locking will no longer work on that channel. If this problem
occurs, appropriate messages will be written to the log file; the problem
can be worked around by either clearing the channel (removing all users
from the channel) or restarting Services. Adding the
NoBouncyModes directive in
ircservices.conf will prevent this problem from occurring, but
will cause mode floods if you have an incorrectly configured server on your
network.
- When kicking users from forbidden channels (or in other cases when a
user tries to join an empty channel and is kicked), Services will generate
debug log messages about "MODE +b for unknown channel". These are
a side effect of the order in which Services processes the operations
involved in the kickban; they are harmless and can be safely ignored. The
same or similar messages can also appear during a netburst when modes are
sent for a channel after all the users in the channel have been kicked, or
when joins and modes are sent for a user who gets autokilled.
- If you try to enter an empty channel and get kicked and banned by
ChanServ, you cannot get in with UNBAN or INVITE even if
you would normally have privileges to do so because ChanServ reports that
the channel does not exist. This is because ChanServ does not keep track
of channels that it is currently residing in after a kickban in the same
way that it does for ordinary users.
- When using protocols that support ban exceptions, users can get
around the "ban" part of a kickban in an empty channel by sending a ban
exception quickly enough that the server processes it before Services is
able to kick the user, allowing the user to repeatedly rejoin the channel
(and get immediately kicked again). This is a side effect of Services not
tracking empty channels in which ChanServ is residing, but if your IRC
server's flood protection is set up properly, this will not be a problem in
practice (there are many ways for users to generate more network traffic
than a join/part loop).
- There appear to be some cases in which channel modes (+k
and +o have been reported) are set twice in succession for the
same channel. This naturally has no effect on the channel itself, but some
users have reported it as annoying. Services attempts to detect and
correct this, but it may still occur in some cases.
- When setting NickServ options for other users as a Services
administrator, NickServ will incorrectly respond with "Your (option name)
has been changed" or similar messages, as though the Services admin's
nickname settings had been changed. (The target nickname's settings are
in fact correctly modified, while the admin's settings are left alone.)
- If you disable one or more of the nickserv/access,
nickserv/autojoin, memoserv/main, and
memoserv/ignore modules, delete a nickgroup, create a new
nickgroup that has the same ID, and re-enable the module(s), the new
nickgroup will keep any data from those module(s) that belonged to the old
nickgroup. Since nickgroup IDs are assigned randomly, this should be a
rare occurrence.
- If you compile on a Macintosh (OSX) system using dynamic modules,
the encryption/unix-crypt module may fail to load. If this
happens, compile using static modules instead (./configure
-use-static-modules).
- If you are not using encrypted passwords, then all passwords will be
truncated to be at most 32 characters (or PASSMAX characters, if
you change the value of PASSMAX in the defs.h source
file) long. As a result, any password with the same initial sequence of
characters will be treated as a match, even if it is not exactly the same
password initially set.
- If a user without auto-op privileges enters a registered, empty
channel and sends a MODE command to change the channel modes before
Services removes the user's channel operator privileges, the changed modes
will remain in effect on the channel. On some IRC servers, such as
InspIRCd and ircd-ratbox, this can be avoided by setting the
CSSetChannelTime
option in modules.conf.
Back to top
Table of Contents