 |
 |
Hi, It's difficult to run xrootd as a normal "Linux-like" service, partially due to (a) the number of running daemons and (b) the possibility of multiple instances per daemon. In Linux, the tradition for starting services is that "service foo start" will start service foo and foo has a single running process. If there's more than one process needed for service foo, then the processes will all be children of the foo daemon. Accordingly, in the separate packaging efforts of Lukasz and I, we have one one service per xrootd daemon: xrootd, cmsd, frm_purged, frm_xfrd. This, however, doesn't play nicely with multiple instances: it's not possible to have a server and a manager and a proxy all on one host. At a WLCG T2 this is probably fine - we just construct a new host or new VM. At smaller sites, having a host per instance is costly. So, I'd like to propose a "xrootd master" daemon. This daemon would parse the config file, determine what services are necessary and what instances are necessary. Then, it will start all the appropriate daemons. When the daemon gets a signal (TERM, HUP, etc), it will pass them accordingly to each of its children. When a children dies unexpectedly, the master will restart it (with exponential backoff). We could even allow a keepalive heartbeat between parent and child; if the child becomes unresponsive, the parent will recycle it. In modern Linux kernels, we can pass the appropriate flags (CLONE_NEWPID) such that the children are killed when the master is - no "escaped" processes allowed. The key here is the master would read the same config file as the other xrootd daemons, keeping the "One Config File To Rule Them All" approach. Thoughts? Brian