IRC Services Manual

Appendix D. Known issues

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. These issues are listed below.

Nickname and NickServ issues

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.

Channel and ChanServ issues

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.
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.
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.

Administration and other issues

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.
When setting another nickname's password or a channel's password as a Services administrator, NickServ (or ChanServ) will send out the "ADMIN used SET PASSWORD as Services admin for TARGET" global message even if the password change is rejected due to length or similarity with the target nickname or channel name. This is difficult to fix cleanly in the current code structure (which is one reason the message was written as "used SET PASSWORD" instead of "changed password"). Since this is expected to be a rare occurrence, clarity of code was given preference over adding special-case processing for this case. Note that setting the NoAdminPasswordCheck option in ircservices.conf will disable all password checks for Services administrators, thus avoiding this problem.
When using the Bahamut protocol, Services will log warnings about missing IP addresses each time an opermasked client connects to the network or rejoins after a netsplit. This is unavoidable on Services' part, since the Bahamut protocol does not seem to provide a way to differentiate between opermasked clients and servers which do not send IP addresses at all.
It has been reported that using the OperServ JUPE command on a Bahamut-based network for a server two or more hops away from the Services uplink server can cause Services to be dropped from the network.
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).

Table of Contents