ATENCION
ATENCION
ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro.
From how I understand it you could send SIGHUP to the child process and it
should terminate gracefully. BUT, I think it also keeps valid connections
alive and therefore can take a lot of time to terminate. Did you try how
SIGHUP behaves?
Okay, so here's the skinny on how signals affect Cyrus:
SIGHUP is for gracefully restarting (e.g. after a config change). You usually send it to master. Processes for services that are no longer enabled in cyrus.conf will be shutdown immediately (see next paragraph). For services that are still enabled in cyrus.conf, master passes on the SIGHUP to the current processes, and they exit at their leisure -- usually when the current client logs out on its own, I think. child_janitor monitors them and cleans up the resources when they eventually exit; it also logs (once only) if they take more than 30s to exit. The current processes may take a long time to actually exit, but those connections will just be running with stale configuration until they do. Any new client connections are served by new processes (with freshly-loaded configuration).
SIGTERM/SIGQUIT/SIGINT are for graceful shutdown (Cyrus treats these three signals identically). If you send it to master it will stop everything -- cleanly, but not "at its leisure". If you send it to a single service process, that process will shut itself down as soon as it finishes processing the command it's currently processing (and master will spawn a replacement as necessary). If you have already arranged that the user will not be able to log in again, or will need to use a new password, you could send one of these three signals to their old sessions to drop them immediately in a safe fashion.
If you want to kill a service with prejudice and not even let it finish what it was doing, SIGKILL will do it, but you'll probably end up with database corruption that you'll then need to figure out how to recover from. So maaaaaaaybe you find this acceptable if you know there's an active malicious connection that you want to end immediately and don't mind cleaning up a mess (AND you know how to clean up such a mess -- I do not). But mostly just don't do it. If you SIGKILL master then I think only master will exit -- all the current service processes will keep running unaffected, but no new connections will be accepted. It doesn't really make any sense to SIGKILL master -- if you want to stop accepting new connections, just shut it all down properly as per the previous paragraph.
As Dave has already observed, if you want to ensure that a user is no longer able to connect (and that their current connections are disconnected ASAP), add them to the user_deny.db, this is exactly what it's for.
If someone has changed their password, then what you want to do kind of depends on why they changed their password.
If they just changed their password because they wanted to change it, then it's fine to do nothing. Their existing connections will stay alive until they end for some other reason, but all their new connections will need the new password.
If they changed their password because they suspected it had been compromised, and they suspect their existing connections may be malicious, you could send SIGTERM/SIGQUIT/SIGINT to their existing connection processes to force a reconnect/relogin. Or you could add them to user_deny.db for a few minutes until the old connections are gone, and then remove them.
Presumably if YOU knew or suspected they were compromised, your first step would be to add them to user_deny.db (thus dropping all their connections and forbidding new ones), and then contact them to change their password. You would then remove them from user_deny.db once you had positive confirmation that they had indeed changed their password.
Otherwise, this really asks for another signal to be defined to do a
forced logout, maybe SIGUSR1 could be used for this task?
SIGTERM/SIGQUIT/SIGINT already take care of this as safely as possible :)
It normally works fine. We just launch a kill TERM to the user's
imap/pop processes mainly.
That seems like the correct thing to do. If you provide DAV or JMAP services then you should also include their http processes in this.
But I have seen a couple of times, that after
doing that, no user can later connect to it's mailbox.
This seems like a bug that you should report when it happens again...
It's like, if
something important would become locked... some important database or
similar, by that killed processes that obviously as have become killed,
won't unlock that hypothetical important database.
Locks work on open files; once a process exits, any locks it held are inherently released, because the files are no longer open. But maybe something prevented the process exiting despite the SIGTERM and it's actually still running. Next time it happens, check carefully to see whether it's still running. If it is, the output from strace(1) may help figure out why. There's not much point speculating further without diagnostics; it may be nothing to do with locking at all...
Cheers,
ellie
------------------------------------------
Cyrus: Info
Permalink:
https://cyrus.topicbox.com/groups/info/Tdfb46db342104c8f-M101e597821a2189e1ec72f40 Delivery options:
https://cyrus.topicbox.com/groups/info/subscription