[systemd-devel] make systemd service takes cpu exclusively
Cao, XinX
xinx.cao at intel.com
Thu Nov 27 02:56:34 PST 2014
Hi,
Yes, you are right. My service is defined as simple. And I changed it to notify, seems that I can make the other services now successfully start after it finished startup. But I'm confused who will call "sd_notify" to send "READY=1"? I can't find the related code in system. Or the program itself?
For example, if the [Service] part of my service file is like this:
[Service]
Type=notify
NotifyAccess = all
ExecStart = /usr/bin/abcdef
... ...
In this service , if I want to use notify type, need I add something like "sd_notify(0,"READY=1")" in the code of "abcdef" ?
-----Original Message-----
From: Andrei Borzenkov [mailto:arvidjaar at gmail.com]
Sent: Thursday, November 20, 2014 01:06
To: Cao, XinX
Cc: Umut Tezduyar Lindskog; systemd-devel at lists.freedesktop.org
Subject: Re: [systemd-devel] make systemd service takes cpu exclusively
В Tue, 18 Nov 2014 06:25:43 +0000
"Cao, XinX" <xinx.cao at intel.com> пишет:
> Hi, Umut & David,
>
> My project needs the Graphical desktop to display on monitor as fast as possible, but I found lots of unrelated services( such as sound, network, ... ) are competing CPU even they are explicitly After graphical service. And this competion delays the startup of graphical desktop process. So, my opinion is to make graphical related programs runs first and the other unrelated services only starts after graphical program finished startup.
Let me guess. Your Graphical desktop is defined of simple or forking, right? So from systemd point of view service is started as soon as process is forked and it proceeds with starting further service defined After this one.
The problem with After is that it is effective only if systemd can know when service startup is completed. And in general it is possible only with types dbus or notify (and cooperating server). In case of GUI you do not even have single process representing service, depending on definition of "Graphical desktop".
More information about the systemd-devel
mailing list