On Fri, 17.10.14 07:03, Paassen, Hiram van ([email protected]) wrote:
> Hi, > > We use systemd to manage some python processes in an embedded > environment (imx28 cpu). This works fantastic except for a fairly long > startup sequence due to python being slow during the initialization of > its standard libraries. > > We found a possible solution inspired by > http://draketo.de/light/english/politics-and-free-software/reducing-python-startup-time > > which basically means taking the startup overhead only once instead of x > times by starting a minimal python process which forks itself into > different programs. > > However, I fail to see how this would play nice with systemd and its use > of cgroups. > > We currently use type=dbus services so I expect that starting is not > really the problem but it would be annoying if systemd cannot stop one > service without killing them all since they are in the same cgroup > > Is it possible to start multiple different services from one process? Such fork hacks will break as soon as some libraries are used which are not Ok with being fork()ed (which is actually the majority, and in all our own libraries we will even detect cases of unexpected forking and refuse to work with ECHILD). Also, it's entirely incompatible with any code that uses threads or locks. Morevoer it is inherently the anti-thesis with systemd's idea of isolating services and giving each a clean, well-defined, execution environment, with a fresh process, including an exec() (which is the only way to get MACs and audit and whatever else properly reset for services). I am sorry, but this fork() hack will not work well together with systemd! Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
