Hi!! I would take a look to signal handling. Perhaps a signal that does a cleaner shutdown than the own TERM exists. In case it doesn’t exist a concrete signal set in the code for this purpose, perhaps TERM directly could be handled for doing the disconnection more “carefully”.
I’ll take again a look to user_deny but yes… in case you don’t send a new command it seems it could take sometime in disconnecting the user… at least I suppose the time a “NOOP equivalent” is sent due to Idle for instance…. Thanks a Lot for the ideas. Any new ones are always welcome :) :) Bye!!! Egoitz, > El 19 oct 2021, a las 23:12, Egoitz Aurrekoetxea <[email protected]> escribió: > > > Good morning, > > > > Thank you so much for your answer. For avoid new logins we can just modify > the user auth database, for avoiding, you know, new logins. > > > > The problem is, how to disconnect appropriately an already connected user > which for instance, gets connected with IDLE or whatever way of keeping > connection alive. Does user_deny.db handle, already logged in users too or > just new logins?. The issue we are suffering is with already logged users. > > > > Thanks a lot again :) :) . Any help very appreciated. > > > > Cheers!! > > > > > > El 2021-10-19 11:50, Dave McMurtrie escribió: > >> >> Hi, >> >> You probably want to use the user_deny.db for this. This is the exact >> use case for which it was implemented. >> >> https://www.cyrusimap.org/imap/reference/admin/sop/userdeny.html >> >> hth, >> >> Dave >> >>> On Mon, Oct 18, 2021 at 3:44 AM Egoitz Aurrekoetxea <[email protected]> >>> wrote: >>> >>> Good morning, >>> >>> >>> We have a feature that allows a user to kill all it's sessions. Imagine a >>> cellphone gets stolen. The user could disconnect it's sessions from our >>> interface. >>> >>> It normally works fine. We just launch a kill TERM to the user's imap/pop >>> processes mainly. But I have seen a couple of times, that after doing that, >>> no user can later connect to it's mailbox. 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. Have you ever seen a behavior like >>> the commented?. >>> >>> Perhaps, does Cyrus have another "more elegant" way of logging out a user?. >>> >>> >>> Best regards, >>> >>> Cyrus / Info / see discussions + participants + delivery options Permalink > Cyrus / Info / see discussions + participants + delivery options Permalink ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/Tdfb46db342104c8f-Mab88421ebd75cda9d26d44c3 Delivery options: https://cyrus.topicbox.com/groups/info/subscription
