Hi Sebastian, > after thinking about it, I think it's like this: I added a service that > was > configured to listen on a privileged port. But master has dropped > privileges by that point, so it can't add such a listener. I just > double-checked that I *can* add a listener at run-time if it's set up to > listen to a non-privileged port. Obvious in hindsight, but perhaps worth > a > note anyway. Oh yeah, of course. I've added the following to man/master.8 for future releases: > Services added or modified to listen on a privileged port may not > be able to bind the port, depending on your system configuration. > In this case a full restart is needed. I'm not entirely sold on the wording, but it's better than the nothing we had. "depending on your system configuration", because looking at the code, if you are running Cyrus on Linux, and if you have compiled it with --with-libcap=yes, then master will actually drop its privileges *before* spawning any services at all, but in such a way that it preserves the capability to bind privileged ports. Assuming that this actually works, then it should also be able to start up new/modified services on privileged ports upon receipt of a SIGHUP. So that's pretty cool. But it's not default: you must be on Linux, have libcap, and explicitly request it at compile time. Cheers, ellie On Tue, Apr 5, 2016, at 04:22 PM, Sebastian Hagedorn wrote: > Hi Ellie, > > --On 5. April 2016 um 14:33:46 +1000 ellie timoney <ellie@xxxxxxxxxxxx> > wrote: > > >> > Sebastian, is there anything you tried that *didn't* work, and if so, > >> > what happened? > >> > >> The only thing I tried that didn't work was to add a IPv6 listener and > >> to HUP the master process. The manpage for master reads (in my version): > >> > >> Cyrus-master rereads its configuration file when it receives a > >> hangup signal, SIGHUP. Services and > >> events may be added, deleted or modified when the configuration > >> file is reread. Any active services > >> removed from the configuration file will be allowed to run until > >> completion. > >> > >> From that it isn't obvious that some class of changes to cyrus.conf > >> apparently require a restart of the service. > > > > I've been looking through master/master.c to see what it actually does, > > and it looks like it matches this documentation. > > > > It does have some commentary in reread_conf() about recycling services > > that have not been removed nor were newly added, which almost sounds as > > if it might have this sort of effect... except that, digging into > > add_service(), it will only reuse entries if their name, listen and > > proto all match (which if you've changed one to IPv6, it won't), and > > otherwise it will be added as a new service (and so reread_conf() will > > treat it as a newly added service, not an existing one to recycle). > > > > I'm pretty tired, and so probably not reading it as closely as I could > > otherwise -- maybe there's a bug or subtlety I've missed -- but: it at > > least /looks like it intends to/ do what the documentation says. So > > it's interesting that it didn't. > > after thinking about it, I think it's like this: I added a service that > was > configured to listen on a privileged port. But master has dropped > privileges by that point, so it can't add such a listener. I just > double-checked that I *can* add a listener at run-time if it's set up to > listen to a non-privileged port. Obvious in hindsight, but perhaps worth > a > note anyway. > > Cheers > Sebastian > -- > .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:. > .:.Regionales Rechenzentrum (RRZK).:. > .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:. > Email had 1 attachment: > + Attachment2 > 1k (application/pgp-signature) ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
