Hi.
How i can check enabled service?
1)
# systemctl enable acpid.service
ln -s '/lib/systemd/system/acpid.service'
'/etc/systemd/system/multi-user.target.wants/acpid.service'
# systemctl is-enabled acpid.service; echo $?
0
OK
2)
# systemctl disable acpid.service
rm '/etc/systemd/system/multi-user
On Mon, May 16, 2011 at 2:46 PM, Lennart Poettering
wrote:
> > It takes about 5-6s for udev to run input_id on the keyboard + touchpad,
> and
> > thus for them to be available to X.
>
> How come this takes so long?
>
> Does this actually delay X? Nromally X should be fine without kbd/mouse
> and t
On Mon, 16.05.11 14:43, Scott James Remnant ([email protected]) wrote:
> On Mon, May 16, 2011 at 2:23 PM, Lennart Poettering
> wrote:
>
> > Our entire userspace bootup takes <1s here on an older X300. I think
> > nobody expects that the mouse reacts any quicker than that.
> >
> Your "older X300"
On Mon, May 16, 2011 at 2:23 PM, Lennart Poettering
wrote:
> Our entire userspace bootup takes <1s here on an older X300. I think
> nobody expects that the mouse reacts any quicker than that.
>
> Your "older X300" is probably rather more powerful than a single-core Atom
CPU.
> But as mentioned e
On Tue, 10.05.11 20:39, Koen Kooi ([email protected]) wrote:
> Signed-off-by: Koen Kooi
Thanks, applied!
(BTW, we don't do S-o-b on systemd)
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
[email protected]
On Sat, 14.05.11 01:29, Alexey Shabalin ([email protected]) wrote:
> This patch rpcbind.target to multi-user.target.
> After apply this path, you can add to rpcbind.service only:
> [Install]
> WantedBy=rpcbind.target
> without multi-user.target.
Hmm, rpcbind.service should pull in rpcbind.tar
On Thu, 12.05.11 09:09, Scott James Remnant ([email protected]) wrote:
> On Mon, May 9, 2011 at 4:32 PM, Lennart Poettering
> wrote:
>
> > On Mon, 09.05.11 13:13, Scott James Remnant ([email protected]) wrote:
> >
> > > The System Daemon seems to be where systemd is much more clever; a
> > Blue
On Thu, 12.05.11 09:01, Scott James Remnant ([email protected]) wrote:
> On Mon, May 9, 2011 at 12:43 PM, Lennart Poettering
> wrote:
>
> > > This means there are a large number of devices already known to the
> > kernel
> > > at the point that systemd starts, especially if you build the drivers
On Mon, May 16, 2011 at 14:27, Lennart Poettering
wrote:
> On Mon, 16.05.11 13:44, Kay Sievers ([email protected]) wrote:
>
>> On Mon, May 16, 2011 at 13:39, Daniel Drake wrote:
>> > On 15 May 2011 15:16, Kay Sievers wrote:
>> >> Just a first quick check of an issue we ran into with ATA disks
On Mon, 16.05.11 13:44, Kay Sievers ([email protected]) wrote:
>
> On Mon, May 16, 2011 at 13:39, Daniel Drake wrote:
> > On 15 May 2011 15:16, Kay Sievers wrote:
> >> Just a first quick check of an issue we ran into with ATA disks:
> >> what's in /proc/sys/kernel/hotplug before you shut dow
On Mon, May 16, 2011 at 14:14, Gustavo Sverzut Barbieri
wrote:
> On Mon, May 16, 2011 at 8:44 AM, Kay Sievers wrote:
>> On Mon, May 16, 2011 at 13:39, Daniel Drake wrote:
>>> On 15 May 2011 15:16, Kay Sievers wrote:
Just a first quick check of an issue we ran into with ATA disks:
what
On Mon, May 16, 2011 at 8:44 AM, Kay Sievers wrote:
> On Mon, May 16, 2011 at 13:39, Daniel Drake wrote:
>> On 15 May 2011 15:16, Kay Sievers wrote:
>>> Just a first quick check of an issue we ran into with ATA disks:
>>> what's in /proc/sys/kernel/hotplug before you shut down? Or what's
>>> CON
On Mon, May 16, 2011 at 13:39, Daniel Drake wrote:
> On 15 May 2011 15:16, Kay Sievers wrote:
>> Just a first quick check of an issue we ran into with ATA disks:
>> what's in /proc/sys/kernel/hotplug before you shut down? Or what's
>> CONFIG_UEVENT_HELPER in your kernel setup, it must be ="" on m
On 15 May 2011 15:16, Kay Sievers wrote:
> Just a first quick check of an issue we ran into with ATA disks:
> what's in /proc/sys/kernel/hotplug before you shut down? Or what's
> CONFIG_UEVENT_HELPER in your kernel setup, it must be ="" on modern
> systems, otherwise the kernel will they to exec()
14 matches
Mail list logo