On Fri, 28.03.14 12:12, Brandon Black (blbl...@gmail.com) wrote: > 4) Socket Activation! I know this is what some will scream when they skim > the above, but it's not a realistic solution in this case for a few reasons: > a) The startup delay, in some cases, can be many whole wallclock > seconds. This is necessary and acceptable in the general sense (this is > network service that people use with large server-side installations, not a > desktop thing).
UDP is lossy anyway, and a startup delay of a few seconds shouldn't be an issue at all. If we are speaking of 15min or so here, that might be a problem, but otherwise this really sounds fine. And if your daemon really takes 15min this sounds like something to look into... > c) Another side-point that might be better addressed in another thread: > even if both of the above weren't true, this daemon uses several sockets > for multiple "roles" internally, some of which share all low-level details > (e.g. two distinct use-cases for multiple TCP sockets that serve different > high-level protocols, where the user might choose arbitrary ports for > both). I'm not seeing any trivial way to distinguish these via socket > activation - perhaps some kind of socket "label" that could be accessed by > the daemon via sd_* APIs to distinguish would be useful here? You can query the listening ports and properties using getsockname() and friends. Also, sd-daemon provides sd_is_socket() which allows you to do similar checks. On our TODO list is to add an "fd store" concept to units where service code can push fds to systemd, and pull them out again (to make reloads nice). At the same time we'd add concept of labelling them. > 5) ExecReexec - this was one of Lennart's musings in the previous thread in > Dec2012. However, this doesn't map well to gdnsd's model if implemented in > the "obvious" manner of having ExecRexec send a signal to the running > daemon to re-exec itself. It would map well if gdnsd could respond to > SIGFOO via fork()->execve() on itself with the "restart" verb and let the > new instance replace itself when it's ready. The problem is that the new > restarting copy needs elevated privileges to bind its sockets, which it > then loses permanently by the time it becomes a real daemon (and thus can't > provide to the newly execve'd copy). In some cases we could pass on the > sockets on by clearing FD_CLOEXEC, but there's no guarantee as to what > socket bindings the new daemon will have: typically the same as before, but > perhaps the address or port number has changed in the config file for one > of five different sockets. At this point in time I am quite sure that ExecReload= should simply be used for this. I am quite sure that "systemctl restart" should do the same thing for all services, and that means stopping the service, followed by starting, and have both of these jobs follow the usual ordering dependency logic (so that other jobs might be order between the stop/start!). OTOH "systemctl reload" should be that verb where some service-specific reload operation is executed, where no restriction is made how this ultimately is implemented, and where no ordering logic really applies. Whether a process reexec is done for this or not is an implementation detail of the specific service, where systemd shouldn't really have to be involved. In general the only suggestion we'd make is that the effect of ExecReload should be synchronous, as comprehensive as possible, yet also as graceful as possible. Reexecing as part of reload sounds like a good idea, if enough care is taken not to stop any ongoing connections or transactions. There have been some changes in systemd a while back that makes sure that ExecReload= can replace the process, so this should pretty much work now if the daemon is up to it. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
