IRC Services Manual

Frequently Asked Questions (FAQ)

Frequently Asked Questions (FAQ) concerning Services

Index:

A. General questions

A.1. What is Services (a.k.a. IRC Services or Services for IRC Networks)?: Services is a package of services for IRC networks. Read the documentation for more information.

A.2. Where can I find Services?: The latest version can always be found at the official Services distribution site.

A.3. Does Services run under Windows?: Services has been reported to run when compiled under the Cygwin [sources.redhat.com] environment for Windows, but has not been tested extensively and is not currently supported by the author. If you need a stable environment, please use a supported environment (such as Linux or FreeBSD).

A.4. How about other operating systems?: Services was at one point reported to be usable under OS/2; however, it has not been tested recently and is not supported. The author has also heard reports of Services being used with moderate success on AmigaOS.

A.5. Can I send in questions without reading the documentation?: Only if you like getting your messages ignored and/or publicly flamed.

A.6. There is no question number 6.

B. Compiling and starting Services:

B.1. Red Hat says GCC 2.96 doesn't have bugs anymore [www.redhat.com]. Why don't you allow it to be used with Services?

Because, as Red Hat themselves admit (and just about anyone involved in Linux development can tell you), some releases of GCC 2.96 did have serious bugs in them, and I have personally verified that at least some releases of 2.96 fail to compile Services correctly. Since Red Hat, in one of their many stupid decisions, chose not to change the version string in the fixed releases, I have no way to tell whether a given release of GCC 2.96 is a "fixed" one or not. Rather than have to wade through assembly listings for every case of a bad GCC release, I've chosen to disallow the use of GCC 2.96 entirely. The previous version of GCC, 2.95.3, is known to work correctly with Services, as are more recent versions (3.2 in particular); either downgrade or upgrade before compiling Services, or install from a binary distribution instead of the source code.

If you absolutely must compile Services using GCC 2.96, you can override the configure check with the -force-gcc-2.96 option. However, the author will not provide support for any problems which occur if you override this check.

Incidentally, Services is believed to not have any of the programming bugs Red Hat discusses on the page referenced above. The one exception is pointer aliasing optimization (the "int i; *(float *)&i = 2.0;" example), which is a bug in the C standard, and is disabled when compiling Services anyway.

B.2. When I run "make", I get an error message like "missing separator", "Need an operator", "Unexpected end of line seen", etc.: Your make program isn't compatible with the Makefile for Services. The Makefile was designed to work with GNU make, version 3.79 or later, and may not work with older versions or other systems' "make" programs. In particular, the make programs bundled with SunOS/Solaris and FreeBSD have been reported not to work; you will need to use GNU make on these systems. See the system requirements section for details.

B.2.5. I get an error like "Makefile.inc not found".: You forgot to run the configure script first. See the installation directions.

B.3. I typed "./ircservices" at the command line, but nothing happened!

Services puts itself in the background when it starts, so you get your shell prompt right back. Meanwhile, Services will continue setting up, then connect to the IRC server specified in ircservices.conf (or on the command line). If it doesn't connect, you probably have the wrong IRC protocol module loaded in ircservices.conf.

Also make sure that you are actually running one of the supported servers. There are many, many different variations on the basic IRC protocol out there, and I have neither the time nor the desire to add support for all of them. See section 2-1 for information on which servers are known to work and not to work with Services. If your server is not listed in the "interoperates" list as a supported server, chances are it will not work. As always, you can check the log file (ircservices.log by default) for error messages.

B.4. I need support for the XYZ protocol.: Tough luck, unless you want to write support for it yourself, or you can supply a complete RFC-style description of the protocol to work from.

B.5. Whenever I start Services, I get a message on my IRC server saying "connection refused" or something similar, and Services gives an error message from the server saying "Closing Link: . . .".: You need to configure your IRC server to accept Services as an IRC server. For most IRC servers (those based on the irc2.x distribution), that involves adding two lines like the following to your ircd.conf file:
C:127.0.0.1:password:services.whatever.net::99
N:127.0.0.1:password:services.whatever.net::99
See the example ircd.conf file provided with most IRC server distributions for the meaning of each field.

B.6. My IRC server is giving me messages like "Connection to services.example.net[127.0.0.1] activated" and then "Access denied -- no N line". Why?: This is typically caused by including a port number in the C:line for Services, which tells your server to try to autoconnect to it (depending on the class (Y:line) settings). This is not what you want, because Services will connect to the server itself, but does not listen for servers to connect to it. The solution is to remove the port number from the C:line.

B.7. When I say "/connect services.*", it doesn't work!: Of course not. RTFM, and see the previous answer.

B.8. Services complains in the logfile about being unable to load the default language, or gives messages like "Warning: bad number of strings (747, wanted 863) for language 0 (en_us)".: You forgot to run "make install" after compiling Services.

C. Running Services:

C.1. Services always dies after about five minutes, saying "FATAL ERROR! Can't back up nick.db".: Make sure that the user Services runs as has write access to the data directory, and that the data directory actually exists (the latter shouldn't be a problem if you installed from a binary distribution or ran the configure script). This means Services needs write and execute permission on the data directory itself and execute permission on every parent directory of the data directory.

C.2. Services can't keep up with my network—it is eventually disconnected with "Max SendQ exceeded". What can I do about this?

If you have a really large network (tens of thousands of simultaneous users), Services in its default configuration may not be able to keep up with all the network traffic. Here are some possible ways to speed Services up:

Run it on a faster computer. (Services does not need to run on the same system as an IRC server! If you have several computers connected via Ethernet or another type of high-speed network, it's perfectly fine to have an ircd on one machine and Services on a separate machine.)
Remove all unneeded modules from ircservices.conf.
Comment out MSNotifyAll in modules.conf (module memoserv/main).
Reduce the nickname and channel expiration periods.
Reduce the size of your autokill, S-line, and session limit exception lists as much as possible, or remove the relevant modules (operserv/akill, operserv/sline, and operserv/sessions) entirely.
Reduce the maximum number of autokicks per channel. (This will not have a direct effect, but it may keep the problem from getting worse.)
Increase the UpdateTimeout setting in ircservices.conf, to reduce the frequency of database synchronization. However, keep in mind that this will mean more potential data loss if/when Services falls off your network or crashes.
Don't run in debug mode!

Services has been successfully used on networks as large as 22,000 simultaneous users with 260,000 registered nicks.

C.3. Services starts up okay, but if I try to register a nickname, it replies with "Sorry, registration failed" or "Internal error - unable to process request.": Make sure you've selected the correct IRC protocol (IRC server) module in ircservices.conf; see question B.3 for details.

C.4. Services crashed with a segmentation fault.: See if you can reproduce this by doing a certain sequence of actions. If so, please report it in detail (see question Z.3 below). If not, you're probably out of luck; if you like, you can report it anyway, but chances are it won't get fixed if it can't be reproduced. If you do have such a problem, you may find the cron utility useful for dealing with it, by making a script to check whether Services is running and restart it if not.

C.5. Services' channel mode setting doesn't work. I can't set modes with OperServ, and every time ChanServ tries to set a mode, my server reverses the change.: If you're running the DALnet, Unreal, or Undernet IRC server, make sure every server on your network has a U:line for Services in ircd.conf; for example:
U:services.whatever.net:*:*
Services will report this in a WALLOPS or GLOBOPS message the first time it discovers it cannot change modes.

C.5.5. But my U:lines are set correctly!: If the ircd.conf file was created, edited, or copied from a Windows computer, then it may be corrupt (Windows inserts ^M characters at the end of every line), which will cause the ircd to not recognize the U:line. Use a text editor (like vi or Emacs) to remove the ^M characters, or re-create the file from scratch.

C.6. My server sometimes sends messages saying "Notice -- User on services.example.net remotely JOINing new channel".: This is normal, and happens whenever ChanServ kicks a user from a channel in which they were the first to enter (for example, a user without privileges entering a channel with the RESTRICTED setting active, or a user on the channel's autokick list). In this case, ChanServ joins the channel for a short period of time to prevent the user from joining again immediately after they've been kicked. If you are using the Bahamut or Unreal IRC servers, this will result in a message like the above; it can be safely ignored.

C.7. How can I make Services send replies using PRIVMSG (/msg) instead of NOTICE?: You can't. RFC 1459 (the IRC protocol definition) requires that all automated clients send all replies using NOTICE rather than PRIVMSG, and Services follows that requirement. If you want to change how Services replies appear in your IRC client, change your client's settings.

C.8. Can I make ChanServ send channel modes all at once instead of one at a time?: Yes; enable the MergeChannelModes directive in ircservices.conf. (Note that this has minor security implications; be sure to read the comments in the example configuration file.)

D. NickServ features:

D.1. Some people get nick collided when their nickname is changed to Guest###.

Make sure you have Guest* (or whatever prefix you specified in ircservices.conf) listed in a Q:line in the ircd.conf file for all of your servers. For example:

Q::Reserved for Services:Guest*

This prevents people from using Guest### nicks and colliding people who get their nicks changed. Note that some IRC servers will generate messages whenever someone gets their nick changed to Guest### by Services and a configuration line like the above is used; you may want to modify your IRC client's configuration so it doesn't display the messages (or change the IRC server itself so it doesn't generate them).

Alternatively, you can set an SQline on the same mask using the OperServ SQLINE ADD (in the operserv/sline module), and Services will take care of making sure all servers have Q:lines for the nick.

D.2. Trying to use REGISTER or SET EMAIL resulted in an "address is unauthorized" message, but the user hasn't registered any nicknames before.: Another user may have set the same E-mail address on their nickname. Use the LISTEMAIL command to see what nicknames have the problem address associated with them.

E. ChanServ features:

E.1. Services ignored the SET SUCCESSOR setting and deleted a channel when the founder expired.: Normally, this is because the successor had too many channels registered; in this case, you will see an entry in the log file like the following:
[date] Successor (SuccessorNick) of channel #somechannel owns too many channels, deleting channel #somechannel
If you don't get a message like this or you can verify that the successor wasn't running into the channel limit, please report it using the bug-reporting procedure below (question Z.3).

E.2. When ChanServ sets the topic for a channel, it always appends "(nickname)" to the end. How do I make it not do that?: This has nothing to do with Services, and is a feature of the IRC server itself which occurs when Services sets the topic on a channel. The "(nickname)" is not actually included in the topic, and the second and later users to join the channel will not see it. There is no way to disable it for the first user, unless you modify the IRC server itself.

E.3. The ACCESS command is confusing to some users. Can you add a channel option to select between the ACCESS and XOP commands?: No. Just tell your users to not use the ACCESS command. (You can also disable the ACCESS command for the whole network by removing or commenting out the LoadModule chanserv/access-levels line in ircservices.conf, but this will prevent even users who understand the ACCESS command from using it.)

E.4. Why can't you force users to register E-mail addresses with channels like you can with nicknames?: Such functionality is unneeded, because ChanServ requires users to register their nicknames before allowing them to register channels. As a result, as long as you require users to include E-mail addresses with nickname, you can just look up the address for the channel founder's nickname if a problem arises with a particular channel.

F. OperServ features:

F.1. Using the OperServ JUPE command results in server messages like "Server juped.server introduced by non-hub server services.example.net" or causes Services to be disconnected.: In all irc2.x-derived IRC servers (and possibly others), every server on the network must have an H:line for Services in the ircd.conf file, which looks something like:
H:*::services.example.net

F.2. I can't use the ADMIN command to add Services administrators—it tells me "Permission denied.": Did you define yourself as the Services super-user? You need to insert your nickname in the ServicesRoot directive in the operserv/main section of modules.conf.

F.3. How can I set up multiple Services super-users?: You can't. However, you can allow Services administrators to obtain Services super-user privilege by setting a password with the OperServ SET SUPASS command; Services admins can then use the SU command to obtain Services super-user privilege.

F.4. When I add an autokill, the users matching it don't get killed.: Services does not kill users when an autokill is added; it only kills them when they next connect. This is designed behavior, intended to reduce the possibility of a mistyped autokill causing the wrong users to get killed. (Suppose you typed "AKILL ADD *@*" and then accidentally hit Enter before finishing the host mask . . .)

F.5. Services reports (via /stats u or /msg OperServ STATS) a different number of users online than I get from doing /lusers.

Services doesn't count its own pseudo-clients (NickServ, ChanServ, etc.) in its user count, so Services will normally report a number somewhat lower than /lusers. This number will vary depending on which pseudo-clients are loaded, and will also change as nickname enforcers are introduced and removed.

If you have a very large and/or busy network, there may be an additional offset, either positive or negative, caused by lag (1) between users signing on/off and Services recognizing them, or (2) between Services killing a user and the servers receiving the kill. On a network with under 500 simultaneous clients, this difference should typically not be more than one at any time, but it can increase quickly as the network grows in size. (If the difference is abnormally large, see question C.2 for ways to speed Services up.)

Finally, you may have encountered a bug in Services. If the difference in counts increases over time without a corresponding increase in the number of users online, then this is the most likely explanation. Make sure you're using the most recent version of Services, then see question Z.3 for how to report the problem.

F.6. Trying to use OperServ gives me "Access denied", but my nick is in the ServicesRoot directive and is registered, and I've identified for my nick.: You need to be opered (i.e. user mode +o from using /oper; this is different from channel operator mode) to access OperServ.

F.7. I used the RAW command to do something, and then Services stopped working!

To quote from the help for the RAW command:

This command has a very limited range of uses, and can wreak havoc on a network or cause Services to crash if used improperly. DO NOT USE THIS COMMAND unless you are absolutely certain you know what you are doing!

In particular, Services does not process any messages sent with the RAW command, so if you (for example) use KILL to kill a user, Services will think the user is still online, and if they connect to the network again Services may well crash, or at least fail to recognize the new user.

To summarize: DO NOT USE the RAW command under any circumstances.

F.8. On Unreal, every time I use the /gline command, Services cancels the G:line.: This is designed behavior. Use the OperServ AKILL command instead of the /gline command.

F.9. Services doesn't add AKILLs/G:lines for users matching autokill masks.: If you have EnableExclude defined in the operserv/akill section of modules.conf, but your IRC server does not support autokill exclusions, then Services will not add AKILLs or G:lines, because doing so would prevent autokill exclusions from working properly. See section 3-4-3 for details.

Z. Bug reporting and feature requests:

Z.1. Services doesn't speak my language!: If you would like to supply a new language module for Services, take a look at lang/en_us.l, which is the language module for English, as well as the comments at the top of lang/langcomp.c, which describe the language file format. If/when you have completed a module for your language, E-mail it to the author for inclusion in Services. However, by sending the author of IRC Services a language file for inclusion in IRC Services, you agree to waive all copyright and other rights to that file and the text it contains, and you agree and state that no one else (such as your employer) has any claims of copyright or any other rights to said file and text. (You will receive credit, of course, but the copyright remains the author's. If you are not sure whether your employer might have rights to your translation, consult with your employer.) Also, it would be very helpful if you would be willing to continue updating the module as changes are made to the base English file.

Z.2. I selected a language other than English, but sometimes Services sends responses in English instead.: Some language files are not complete—in other words, they don't have a translation of every message Services uses, but only some of them. In this case, the missing messages will be displayed in English (or in the default language set in defs.h, if that language file has the appropriate message). You can either wait for the primary translator to complete the translation, or do the translation yourself and send the author the messages translated into your language.

Z.3. I've found a bug that's not mentioned here or in the documentation or KnownBugs files. What should I do?

First, check the Services home page and make sure you have the most recent version of Services; if not, upgrade to the most recent version before reporting your bug, because it may have already been fixed.

If you already have the most recent version, or upgrading does not fix the problem, contact the mailing list and report it. Make certain you include as many details as possible, even things which seem obvious to you--because they may not be obvious to other people. (I have seen bug reports like "I have a problem with expiring nicks and channels"; this is useless, because it doesn't give any details on what the "problem" is, such as when it happens, what the last-used times of the nicks and channels were, or anything else that could be used to find the alleged bug.) Include at least the following information:

The version of Services you're using
The operating system (name and version) and type of machine (CPU) you're using
What you did that caused the problem
What Services did in response
What you think Services should have done instead
Whether the problem happens every time or just occasionally

If possible, try and reproduce the problem on a clean install (i.e. empty databases), starting from registration of nicknames and channels; this will help pinpoint where the problem is.

You may be asked for a "debug log"; this means a log created by starting Services with the -debug command-line option, which writes a lot of debugging information to the log file (such as data received from and sent to the uplink server). Note that the logfile can grow in size quickly when debugging is active, so make sure you have enough disk space available It may be convenient to use the -log option as well, to write the log to a different file than the default logfile; for example:

ircservices -debug -log=debug.log

If you do not get a response to your message to the mailing list in a reasonable amount of time, or for some reason you cannot subscribe to the mailing list (you must subscribe in order to send mail to the list), then you can try contacting the author directly.

Z.4. Your Services program doesn't do such-and-such like DALnet Services. What's wrong?: Nothing is wrong, except your expectations. IRC Services is a completely different program from the Services program used on DALnet; they are similar in concept only.

Z.5. I've got a great new idea for Services. Do you want it?

New ideas are always welcome; however, not all ideas will necessarily be included in Services. Some suggestions are simply impossible or not feasible to implement; others, even if technically possible, would complicate and/or slow down Services too much for too little benefit. In general, new features should have wide applicability (be useful for many people) and be as simple as possible to use, and they should not duplicate features provided just as well or better by another program (such as an Eggdrop bot or the like). If you have written code to implement your suggestion, feel free to send it along with (but not instead of!) a description of the suggestion itself.

If your suggestion is not accepted, you are of course welcome to implement it and distribute it yourself, either as a patch to Services or as a completely separate program.

Z.6. Examples of feature suggestions, and why they haven't been added:

An option to make ChanServ stay in some/all registered channels: I see absolutely no necessity for this feature, since (1) Services' channel privilege and information functions will operate whether or not ChanServ (or any users at all) are in the channel, and (2) if someone really wants to keep a channel open for some reason, they can use an ordinary bot. Furthermore, having ChanServ stay in channels will dramatically increase the amount of traffic Services has to handle, which will in turn reduce the rate at which Services can respond to requests. (This has also been discussed to death on the mailing list, so please don't ask for it to be reconsidered.)
Automatic handling for unusual situations: For example, an option to allow users who have owned their nick for a long time and want to go on vacation for longer than the nickname expiration period. Services is an assistant, not a babysitter; it provides tools to help you manage your IRC network, but it will not run the network for you. Situations like the above can already be handled using Services commands (for example, /msg NickServ SET nickname NOEXPIRE ON); it is not worth the added complexity, in both the programming and the configuration of Services, to automate such rare circumstances.
A "current time" field in NickServ and ChanServ INFO displays: Most people have clocks of some sort either on their computer screens or on their walls (or both), and all IRC servers, as well as Services, have a command to return the server's current time; it is also possible to set the time zone Services displays dates and times in (NickServ SET TIMEZONE). Thus a current-time field in INFO displays would simply take up extra space for no reason.

Z.7. I submitted a bug report / feature request and it got fixed / added, but I didn't get credit in the Changes file!: You may have reported it after it was already fixed or added. In general, the Changes file lists only the first person to submit the bug report or feature request, except when that person is the author or a lot of people all report the same problem or request, in which case no individual credit is given. Mistakes do happen, though; if you really think you should be given credit for something, or if you find yourself being given credit for something that wasn't yours, please inform the author.

Z.8. Can I be a Services developer too?

The short answer is, no.

The long answer is, while I accept suggestions and patches from others, I have tough standards on what code I actually allow into Services itself; in fact, even when I get a patch, I never use it as is but rewrite it so that it fits in with the rest of the Services code properly. This is the main way I'm able to keep Services as stable and coherent as it is: I don't let anyone else touch the actual code base.

Every now and then I have someone tell me, "But it's open source! You have to let other people help too!" This is, however, a misunderstanding of what open source is about. Open source is not about having lots of people work on a single project; that's the "bazaar model" of software development, popularized by Eric S. Raymond's essay "The Cathedral and the Bazaar" [www.tuxedo.org] (and I don't entirely agree with his arguments, but that's another story). Open source is only about giving users of software the freedom to modify that software as they see fit, by giving them a copy of the source code for the software; the difference is that those users may not necessarily be all working together on a single project, and may even be in "competition" with one another, so to speak, by each releasing their own version of a program. While it may seem that this wastes effort, the advantage is that each of those people has their own ideas for what the software should do; each program evolves in its own way, letting people experiment with more features, more ways of doing things than if they were all working on a single program. This is, in fact, the case with Services as well; I have personally seen around a dozen derivatives of my Services program, each with its own particular changes, and I have taken several ideas from those other programs as well.

So in summary, while you're welcome to contribute ideas (or patches), and you're also welcome to take the Services source code and start your own version of it, I have no plans to allow anyone else direct access to the Services development code base or to delegate out various functions or modules to other people.

Table of Contents | Top