# IRC Services Manual

## Frequently Asked Questions (FAQ)

Table of Contents

## 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)?
A.2. Where can I find Services?
A.3. Does Services run under Windows?
A.4. How about other operating systems?
A.5. Can I send in questions without reading the documentation?
A.6. There is no question number 6.

### B. Compiling and starting Services

B.1. (deleted)
B.1.5. Why does `configure` complain that my compiler has bugs in it? Can't you work around them?
B.2. `configure` reports that my system doesn't have the `strtok()` function. Isn't that a bug?
B.3. When I run "`make`", I get an error message like "`missing separator`", "`Need an operator`", "`Unexpected end of line seen`", etc.
B.3.5. I get an error like "`Makefile.inc not found`".
B.4. (deleted)
B.5. I need support for the XYZ protocol.
B.6. 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:` . . .".
B.7. 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?
B.8. When I say "`/connect services.*`", it doesn't work!
B.9. 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)`".

### C. Running Services

C.1. Services keeps giving errors saying that the data directory is locked and the databases won't be updated.
C.1.5. Services is giving "Can't create temporary database file" errors.
C.2. Services can't keep up with my network—it is eventually disconnected with "`Max SendQ exceeded`". What can I do about this?
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.`"
C.4. Services crashed with a segmentation fault.
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.
C.5.5. But my U:lines are set correctly!
C.6. My server sometimes sends messages saying "`Notice -- User on services.example.net remotely JOINing new channel`".
C.7. How can I make Services send replies using `PRIVMSG` (`/msg`) instead of `NOTICE`?
C.8. Can I make ChanServ send channel modes all at once instead of one at a time?
C.9. I sometimes get errors in the log file about "user record not found", "non-existent nick", or "unknown channel". What are these?
C.10. Long messages from Services sometimes get a colon (":") inserted in the middle.
C.11. Services crashes when loading databases on SPARC systems.
C.12. When using Services with InspIRCd, the IRC server gives a warning about "nonstandard modes".

### D. NickServ features

D.1. Some people get nick collided when their nickname is changed to `Guest###`.
D.2. Trying to use `REGISTER` or `SET EMAIL` resulted in an "address is unauthenticated" message, but the user hasn't registered any nicknames before.

### E. ChanServ features

E.1. How do I make ChanServ join/stay in a channel?
E.2. Services ignored the `SET SUCCESSOR` setting and deleted a channel when the founder expired.
E.3. When ChanServ sets the topic for a channel, it always appends "`(nickname)`" to the end. How do I make it not do that?
E.4. The `ACCESS` command is confusing to some users. Can you add a channel option to select between the `ACCESS` and `XOP` commands?
E.5. Why can't you force users to register E-mail addresses with channels like you can with nicknames?
E.6. If I use `SET MLOCK` on a channel to set a key, then anyone who enters the channel when empty can see it! How do I avoid this?
E.7. (deleted)
E.8. If a channel operator sets mode `-o+v` on himself, ChanServ always sends `-v`.
E.9. ChanServ `UNBAN` doesn't work properly on Unreal.
E.10. Why are the `STATUS` error messages so strange? Why doesn't `STATUS` obey the language setting in NickServ?
E.11. Whenever a user enters an empty channel, I see messages about "channel TS", and the user loses and then gets channel ops again.
E.12. When a user is autokicked from a channel, sometimes Services doesn't ban them and they get stuck in a join/kick loop.

### 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.
F.2. I can't use the `ADMIN` command to add Services administrators—it tells me "`Permission denied.`"
F.3. How can I set up multiple Services super-users?
F.4. When I add an autokill, the users matching it don't get killed.
F.5. Services reports (via `/stats u` or `/msg OperServ STATS`) a different number of users online than I get from doing `/lusers`.
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.
F.7. I used the `RAW` command to do something, and then Services stopped working!
F.8. On Unreal, every time I use the `/gline` command, Services cancels the G:line.
F.9. Services doesn't add `AKILL`s/G:lines for users matching autokill masks.
F.10. Services doesn't kill users matching a newly-added autokill mask even if `ImmediatelySendAutokill` is set.

### Z. Bug reporting and feature requests

Z.1. Services doesn't speak my language!
Z.2. I selected a language other than English, but sometimes Services sends responses in English instead.
Z.3. I've found a bug that's not mentioned here or elsewhere in the documentation. What should I do?
Z.3.5. What's a "backtrace", and how do I get one?
Z.4. Your Services program doesn't do such-and-such like DALnet Services. What's wrong?
Z.5. I've got a great new idea for Services. Do you want it?
Z.6. (deleted)
Z.6.5. (deleted)
Z.7. I submitted a bug report / feature request and it got fixed / added, but I didn't get credit in the `Changes` file!
Z.7.5. I don't want my name / E-mail address publicly available in the Changes file.
Z.8. (deleted)

Back to top

### A. General questions

A.1. What is Services (a.k.a. IRC Services or Services for IRC Networks)?

  Services is a software package providing various services such as nickname and channel registration 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 supported by the author. If you need a stable environment, please use a supported operating system (such as Linux or FreeBSD).

  One user has reported success in running Services as a Windows service; however, the database files must be owned by the Windows user under which Services runs (e.g. Administrator), and the files' security properties must be changed to prevent the file owner from being altered.

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.

Back to top

### B. Compiling and starting Services:

B.1. (deleted)

B.1.5. Why does `configure` complain that my compiler has bugs in it? Can't you work around them?

  GCC versions earlier than 3.4 have bugs which cause the `__builtin_apply()` and `__builtin_return()` pseudofunctions to be miscompiled (see GCC Bugzilla, bugs 8028 and 11151 [`gcc.gnu.org`], for details). Working around this problem requires the use of assembly language, so workarounds are platform-specific; Services has workarounds for these bugs on the Intel x86, SPARC, and PowerPC platforms, but on other systems, you will need to use GCC 3.4 or later, or the `configure` script will report an error and refuse to continue.

B.2. `configure` reports that my system doesn't have the `strtok()` function. Isn't that a bug?

  Many system libraries, including those used with Linux and Solaris, have subtle bugs in their `strtok()` implementations which cause Services to perform improperly, or even crash in some cases. The `configure` script checks for these bugs, and reports `strtok()` as "not found" if one or more bugs are present. (In fairness, the definition of `strtok()` is vague in some respects, and developers of these libraries may have interpreted it differently than the way it is used in Services.)

B.3. 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.3.5. I get an error like "`Makefile.inc not found`".

  You forgot to run the `configure` script first. See the installation directions.

B.4. (deleted)

B.5. I need support for the XYZ protocol.

  Services can be made to support new IRC protocols with the addition of new protocol modules. You will need to write a protocol module to support the specific protocol you want to use; see the technical manual for details.

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

  Note particularly that "no N:line" errors can mean any of several things:

  - Services' IP address or host name is different than that in the first parameter to the `N:` line. On some systems, using "`localhost`" in the `RemoteServer` configuration directive will not always get you the IP address `127.0.0.1`! To check what hostname or IP address the IRC server thinks you have, start up an IRC client on the same machine you are running Services on, connect to the server given in the `RemoteServer` directive, and do a `/whois` on yourself; the hostname in the `/whois` response should be used as the first `N:` line parameter.

  - Your IRC server has been compiled to use encrypted `N:` line passwords but you gave a plaintext password as the second `N:` line parameter, or vice versa.

  - The server name given as the third `N:` line parameter does not match the name given in the `ServerName` configuration directive. The third parameter is not the IP address or hostname of the remote server (Services in this case), but rather the server name presented in the server registration (`SERVER`) message; this is an important distinction that can be easily forgotten.

B.7. 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.8. When I say "`/connect services.*`", it doesn't work!

  Of course not. RTFM, and see the previous answer.

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

Back to top

### C. Running Services:

C.1. Services keeps giving errors saying that the data directory is locked and the databases won't be updated.

  This can occur if Services was interrupted (e.g., by a power failure) or crashed while writing the databases. Remove the file given in the warning message (this is the file specified by the `ircservices.conf` `LockFilename` directive, by default "`.lock`" in the Services data directory), then use the OperServ `UPDATE` command to save the databases; alternatively, the `FORCE` option can be used with the OperServ `UPDATE` command to perform both steps at once.

C.1.5. Services is giving "Can't create temporary database file" errors.

  Make certain that (1) the disk on which the databases are stored is not full, and (2) that Services has permission to create files in the data directory (on Unix systems, this means that the user-ID that Services runs as must have write and execute permission on the data directory, as well as execute permission on all parent directories 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`.
  - Configure Services with the `-no-sorted-lists` option and recompile. (This will speed up nickname and channel access, but commands like NickServ and ChanServ LIST will no longer return names in alphabetical order.)
  - 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`, as described in section 2-4.

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; the `ircservices-chk` script, installed in the same place as the `ircservices` executable, will check whether Services is running and restart it if not (see section 2-6 for details).

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

C.9. I sometimes get errors in the log file about "user record not found", "non-existent nick", or "unknown channel". What are these?

  These messages can appear when Services disconnects a user from the network or removes (kicks) a user from a channel, and are the result of time lag inherent in all networked systems. For example, if an autokilled user connects to the network and immediately sends a `/join` command to join a channel, the user's server may receive the `/join` before it receives the disconnection message from Services. Services will then receive the `/join` for what it thinks is a user who no longer exists, and reports that it received a message for a non-existent nickname.

  These messages do not indicate a bug or other problem, and can be safely ignored.

C.10. Long messages from Services sometimes get a colon (":") inserted in the middle.

  This is caused by a bug in the "mIRC" IRC client for Windows computers; if you try to send a very long message using the `/operserv` (or `/nickserv`, etc.) command, such as a long global notice, then mIRC will insert a colon in the middle of it. There is nothing Services can do to fix this, since Services can't tell whether the colon was intentionally put there or not. If you experience this problem, try upgrading mIRC to the latest version or using another IRC client. Alternatively, as a workaround you can use `/msg OperServ` instead of `/operserv`.

  See also this thread [`trout.snt.utwente.nl`] on the mIRC forums.

C.11. Services crashes when loading databases on SPARC systems.

  This is due to a bug in some versions of GCC running on SPARC systems. Services contains a temporary workaround for this problem, but it is very compiler- and environment-specific, and it may not work for you. The bug has been filed in the GCC bug database as bug 11151 [`gcc.gnu.org`], and has been fixed as of GCC 3.4.

C.12. When using Services with InspIRCd, the IRC server gives a warning about "nonstandard modes".

  A message like the following:

  > `WARNING: The server services.example.net is sending nonstandard modes: 'ChanServ MODE +r' where FMODE should be used, and may cause desyncs.`

  is a side effect of the way Services works, and can be safely ignored; the "may cause desyncs" text does not apply to Services.

Back to top

### 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, if your IRC server supports SQlines, you can set an SQline on the same mask using the OperServ `SQLINE ADD` command (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 unauthenticated" 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.

Back to top

### E. ChanServ features:

E.1. How do I make ChanServ join/stay in a channel?

  You don't. Use a bot instead.

E.2. 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.3. 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.4. 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.5. 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 nicknames, you can just look up the address for the channel founder's nickname if a problem arises with a particular channel.

E.6. If I use `SET MLOCK` on a channel to set a key, then anyone who enters the channel when empty can see it! How do I avoid this?

  Set the `RESTRICTED` option for the channel, as described in the help for `SET MLOCK`, or use a bot to keep the channel open.

E.7. (deleted)

E.8. If a channel operator sets mode `-o+v` on himself, ChanServ always sends `-v`.

  This is a side effect of security measures which prevent non-autoop users from getting a `+v` in before Services deops them. Either do the `+v` before the `-o` or use the ChanServ `VOICE` command.

E.9. ChanServ `UNBAN` doesn't work properly on Unreal.

  In recent versions of Unreal, it is possible to set bans on a user's IP address. However, Unreal 3.2 servers do not send client IP address information to Services, so it is impossible to tell which IP-address bans match the user; thus the `UNBAN` command will fail to remove them. Unreal 3.2.1 and later do send IP addresses to Services, so if you upgrade all of your servers the problem will go away.

E.10. Why are the `STATUS` error messages so strange? Why doesn't `STATUS` obey the language setting in NickServ?

  The `STATUS` command is intended primarily for use by bots, to allow them to take advantage of access level information stored in Services. For this reason, the responses to the `STATUS` command, including error messages, need to have a fixed format that can be understood by a computer.

E.11. Whenever a user enters an empty channel, I see messages about "channel TS", and the user loses and then gets channel ops again.

  These messages and mode changes are harmless, and are caused by the `CSSetChannelTime` configuration option (see also the relevant part of section 3-2-1). This functionality is implemented by sending a message to the network that Services has the "proper" timestamp (TS) and modes for the channel. Unfortunately, many IRC servers blindly cancel their own modes, including the channel ops of the user who initially joined the channel, before noticing that Services is not actually changing any modes; this results in the server sending out a "`-o`" mode change immediately followed by a "`+o`". Some servers also seem to think that the timestamp change is a bug (or hack attempt) and send out a warning to IRC operators about it.

  All of these messages are harmless and can be safely ignored, but if they bother you, you may want to consider disabling the `CSSetChannelTime` option.

E.12. When a user is autokicked from a channel, sometimes Services doesn't ban them and they get stuck in a join/kick loop.

  If you are using the Unreal IRC server, this may be caused by "extended ban types", specifically third-party Unreal modules that add ban types beyond the standard types in Unreal 3.2 (`q`, `n`, `c`, and `r`); Services cannot support these ban types. Try disabling such modules and see if the problem persists.

Back to top

### 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`. Also make sure that you have registered and identified for your nickname, and that you have IRC operator privileges.

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 is intended primarily for testing of Services and IRC servers; it has a very limited range of uses on a live network, 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 (for example) you use `KILL` to kill a user, Services will think the user is still online, and if they connect to the network again Services may fail to recognize the new user, or even crash.

  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 `AKILL`s/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 `AKILL`s or G:lines, because doing so would prevent autokill exclusions from working properly. See section 3-4-3 for details.

F.10. Services doesn't kill users matching a newly-added autokill mask even if `ImmediatelySendAutokill` is set.

  Services never kills users when a new autokill is added; the `ImmediatelySendAutokill` configuration directive only causes Services to send the autokill itself (that is, the user/host mask to prohibit new connections from) to the IRC servers on your network. This is a safety feature intended to limit the damage caused by a mistyped autokill. (See also question F.4 above.

  Note that some IRC servers will themselves kill users matching a newly-added autokill; this is unrelated to Services.

Back to top

### Z. Bug reporting and feature requests:

Z.1. Services doesn't speak my language!

  If you would like to add a new language module to 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. To allow Services to use the new language module, you will need to add a new `LANG_*` constant to the `language.h` source file and update the `language.c` and `lang/Makefile` files accordingly. See section 2-8 of the technical manual for details.

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

Z.3. I've found a bug that's not mentioned here or elsewhere in the documentation. 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. Also check the setup of your IRC network and Services; for example, make certain you have the proper IRC protocol module loaded. The Services log file (`ircservices.log` by default) may contain information that will help you locate the problem.

  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 (do not say "the latest version"—give the actual version number)
  - 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 the problem involves Services crashing (such as with a segmentation fault), then you should also provide a "backtrace"; see the next question (Z.3.5) for details.

  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.3.5. What's a "backtrace", and how do I get one?

  A "backtrace" is a list of what functions have been called in order to reach a certain point in a program. For example, the function `main()` may have called a function `foo()`, which in turn called a function `bar()`, so the backtrace at a point inside function `bar()` would look like:

  - Level 0: `bar()`
  - Level 1: `foo()`
  - Level 2: `main()`
  This can be thought of tracing the path of execution back to the beginning of the program, hence the term "backtrace".

  Backtraces are most useful in determining where (and often why) a program crashed, since they indicate both the exact point at which the program crashed and the sequence of actions that led to the crash; for this reason, they are a standard feature of most debuggers. The instructions below are for the GNU debugger, GDB, but should be mostly applicable to other debuggers as well.

  The most common way to obtain a backtrace is from a core file, a file created when a program crashes that contains information about the program's state at the time of the crash. However, Services normally avoids the creation of core files in order to provide a somewhat cleaner response to such emergency conditions. In order to force Services to create core files, it is necessary to pass the `-dumpcore` option to the `configure` script and recompile Services. Additionally, since compiler optimization can cause the crash location to be reported incorrectly, and since the default compilation options do not include debugging information helpful in interpreting a backtrace, it is preferable to turn optimization off and debugging on by using the `configure` option "`-cflags -g`". The following command line can be used to enable core dumps:

  > `./configure -dumpcore -cflags -g`

  Once you have reconfigured Services, compile, install, and start it as usual. When a crash occurs, a core file will be created, usually named "`core`" or "`ircservices.core`" and usually stored in the Services data directory (though both of these are operating system dependent). This file can be used to generate a backtrace for the program at the time of the crash.

  To generate the backtrace, load the program and core file into the debugger with the command line:

  > `gdb executable-file core-file`

  For example, if your Services executable file is located in `/usr/local/sbin`, your data directory is `/usr/local/lib/ircservices`, and the core file is named `core`, you would use:

  > `gdb /usr/local/sbin/ircservices /usr/local/lib/ircservices/core`

  After the executable and core file have been loaded, you will be presented with a "`(gdb)`" prompt. Type "`bt`" (short for "backtrace") and press Enter at this prompt, and the backtrace will be printed.

  If Services still does not produce a core file after following the above instructions, it is possible to obtain a backtrace from the program as it is running. To do this, recompile Services as above, but instead of starting it the ordinary way, first load it into GDB:

  > `gdb executable-file`

  and then run Services in the foreground, rather than in the background as usual:

  > `run -nofork`

  When the program crashes, GDB will print a message like "`Program received signal SIGSEGV, Segmentation fault`", and you will be presented with the "`(gdb)`" prompt. If you type "`bt`" at this prompt, you will be able to get a backtrace as above.

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?

  As of version 5.1.0, I have ended Services development, so I am no longer accepting feature requests.

Z.6. (deleted)

Z.6.5. (deleted)

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.7.5. I don't want my name / E-mail address publicly available in the Changes file.

  Please contact the author with your request. However, be aware that all messages to the mailing list are archived and publicly available, including E-mail addresses (though the addresses are obfuscated to deter address-gathering robots).

Z.8. (deleted)

Back to top

Table of Contents