/modrestart used to be implemented as a normal command and could crash
when used remotely because it would reload m_encap, which was on the
call stack at the time. This was fixed in 41390bfe5f. However,
/modreload has exactly the same problem, so I'm giving it the
same treatment.
Incidentally: This bug was first discovered in ircd-seven, where the
`/mod*` commands themselves live in the core, so m_encap was the only way
the crash could happen (and it didn't most of the time, because m_encap
would only be moved if you got unlucky). But `/mod*` are in modules in
charybdis, so /modrestart would have unloaded the code it was in the
middle of executing. With that in mind, I'm not sure how it ever
appeared to work.
Reloading modules sends CAP DEL followed by an immediate CAP NEW:
:staberinde.local CAP * DEL :account-tag
:staberinde.local CAP * NEW :account-tag
This isn't very nice. /modrestart is particularly bad. In order to avoid
doing this, we remember the capability set at the beginning of module
operations, compare that with the set afterwards, and report only the
differences with CAP {DEL,NEW}.
ENCAP module. The ms_encap function is responsible for dispatching the
command handler and then the modules will eventually be reloaded.
However, if the ENCAP module is reloaded to a different address, the
stack now contains the address of a function that no longer exists.
Also, in this version of the IRCd, the module restarting functionality
was located in a function that is itself located in a module, so things
will also go badly if that module is reloaded to a different address,
too.
Return immediately from the command handler and have the event loop
call the function responsible for reloading the modules instead.
c.f. release/3.5 commit db05a36210
Reported-by: mniip (Freenode)
This will allow service process monitoring to recognise the difference
between a shutdown and an error of a -foreground ircd, because only
/DIE (or SIGINT) will exit with return code 0.
There's no reason to really have these in the main ircd anymore, static
modules are dead and aren't coming back.
To ensure people don't do something hopelessly retarded, this is a core
module.
.la archives are prohibited by most Linux distributions because they
clutter up the linker. They may get caught up as victims in scripts that
purge .la files. Besides, .la files don't matter for simple loadable
modules on most systems.
So, what we do now instead is just use the platform suffix detected by
libtool.
Also fix up some return values and stuff to use bool (or void if
nothing). I just did it whilst I was here.
According to jilles, the return value used to signify whether or not the
client had exited. This was error-prone and was fixed a long, long time
ago, but the return value was left int for historical reasons.
Since the return type is not used (and has no clear use case anyway),
it's safe to just get rid of it.
MAPI V1 is still supported for legacy modules, but it is highly
recommended to update to MAPI V2. It includes support for capability
tables, module descriptions, and implicit versions.
