On Tue, 02.09.14 10:06, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > Hi, > > I would like to start a configurable set of services first and the > services are wanted by multi-user.target. I am using a service to jump > to multi-user.target and I was wondering if we can support this use > case natively by systemd. > > multi-user.target.wants > A.service > B.service > C.service > D.service > > default.target > stage.target > stage.target.wants (These are set by generator) > A.service > C.service > switcher.service > > switcher.service (This is generated by generator) > [Unit] > Description=Switch to multi-user.targe > After=A.service C.service > [Service] > Type=oneshot > RemainAfterExit=yes > ExecStart=/usr/bin/systemctl --no-block start multi-user.target > > This way I am jumping from one target to another target during runtime. > > - What stage.target wants is dynamic. If it was static, my job would > have been very simple. > - I am aware of StartupCPUShares but it is not the ultimate solution > A) there is a configurable minimum quota in CFS which still gives CPU > to other processes. B) We still fork other processes and this causes > changes in timeout values of other processes. > - Adding dynamically After= to B and D service files is not the > ultimate solution either because B and D might be socket/dbus > activated by A or C. > > Should this be something we should support natively by systemd?
As discussed at th systemd hackfest: I am a bit conservative about this as it introduces plenty chance for deadlocks, where services might trigger/request some other unit but we'd delay it until the later stage... I think the implementation you chose is actually pretty good. I am not sure though that we should do this upstream. I mean, I really would prefer if we'd dump as much work as possible on the IO elevator and CPU scheduler, and then adjust the priorities of it to give hints what matters more. Trying to second-guess the elevator and scheduler in userspace feels a bit like chickening out to me, even though I am sure that it might be something that one has to do for now, in the real world... There's one change I'd really like to see done though in systemd, that might make things nicer for you. Currently, it's undefined in systemd which job is dispatched first, if multiple jobs can be executed. That means when we are about to fork off a number of processes there's no way to control which one gets forked off first. I'd be willing to merge a patch that turns this into a prioq, so that some priority value can be configured (or automatically derived) for each unit, and the one with the highest priority would win, and be processed first. This would not provide you with everything what you want, but would make things a bit nicer when we dump all possible work on the scheduler/elevator, because after all we cannot really dump all work at the same time, and hence should at least give you control in which order to dump it, if you follow what I mean. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel