Discussion:
How do I disable old init.d scripts?
(too old to reply)
Paul Menzel
2012-06-25 13:25:19 UTC
Permalink
Dear systemd folks,


how can I disable init.d scripts which systemd loads for compatibility
reasons?

$ ls /etc/init.d/motd (or any other init.d script)
/etc/init.d/motd
$ systemd-analyze blame | grep motd
543ms motd.service
$ sudo systemctl disable motd.service
Failed to issue method call: No such file or directory


Thanks,

Paul
Koen Kooi
2012-06-25 13:31:25 UTC
Permalink
Post by Paul Menzel
Dear systemd folks,
how can I disable init.d scripts which systemd loads for compatibility
reasons?
$ ls /etc/init.d/motd (or any other init.d script)
/etc/init.d/motd
$ systemd-analyze blame | grep motd
543ms motd.service
$ sudo systemctl disable motd.service
Failed to issue method call: No such file or directory
Try:

systemctl mask motd.service

regards,

Koen
Paul Menzel
2012-06-26 22:55:33 UTC
Permalink
Post by Koen Kooi
Post by Paul Menzel
how can I disable init.d scripts which systemd loads for compatibility
reasons?
$ ls /etc/init.d/motd (or any other init.d script)
/etc/init.d/motd
$ systemd-analyze blame | grep motd
543ms motd.service
$ sudo systemctl disable motd.service
Failed to issue method call: No such file or directory
systemctl mask motd.service
That worked and userspace now takes less than three seconds on the
Debian Sid/unstable system.


Thanks a million,

Paul
Lennart Poettering
2012-06-27 09:14:50 UTC
Permalink
Post by Paul Menzel
Post by Koen Kooi
Post by Paul Menzel
how can I disable init.d scripts which systemd loads for compatibility
reasons?
$ ls /etc/init.d/motd (or any other init.d script)
/etc/init.d/motd
$ systemd-analyze blame | grep motd
543ms motd.service
$ sudo systemctl disable motd.service
Failed to issue method call: No such file or directory
systemctl mask motd.service
That worked and userspace now takes less than three seconds on the
Debian Sid/unstable system.
You should be able to pull this down to < 1s with some love... ;-)

Just for he sake of curiosity, could you post the output of
"systemd-analyze plot" somewhere?

Lennart
--
Lennart Poettering - Red Hat, Inc.
Paul Menzel
2012-06-27 10:18:02 UTC
Permalink
Post by Lennart Poettering
Post by Paul Menzel
Post by Koen Kooi
Post by Paul Menzel
how can I disable init.d scripts which systemd loads for compatibility
reasons?
$ ls /etc/init.d/motd (or any other init.d script)
/etc/init.d/motd
$ systemd-analyze blame | grep motd
543ms motd.service
$ sudo systemctl disable motd.service
Failed to issue method call: No such file or directory
systemctl mask motd.service
That worked and userspace now takes less than three seconds on the
Debian Sid/unstable system.
You should be able to pull this down to < 1s with some love... ;-)
Just for the sake of curiosity, could you post the output of
"systemd-analyze plot" somewhere?
I was hoping you will write that. Please find the files attached.

chrony and VDR still use the init.d scripts. For chrony I have not yet
come around to try the service files [1]. For VDR I started a thread on
***@linuxtv.org [2] (although this looks to be complicated thinking of
all the use cases).

Looking at the `systemd-analyze plot` output I would think PulseAudio
not depending on NetworkManager and GDM3 – maybe start in parallel to
NetworkManager and then wait for network connection – could start
earlier too.

And lastly the mainboard is an ASRock E350M1 (AMD Fusion E-350) and it
is a crucial m4 256 GB SSD [3]. I added the GDM3 service file and
disabled the init.d script motd. Everything else should be a standard
Debian Sid/unstable system.


Thanks,

Paul


[1] http://lists.freedesktop.org/archives/systemd-devel/2012-June/005596.html
[2] http://linuxtv.org/pipermail/vdr/2012-June/026487.html
[3] http://lists.freedesktop.org/archives/systemd-devel/2012-May/005181.html
Lennart Poettering
2012-06-27 10:35:46 UTC
Permalink
Post by Paul Menzel
Post by Lennart Poettering
You should be able to pull this down to < 1s with some love... ;-)
Just for the sake of curiosity, could you post the output of
"systemd-analyze plot" somewhere?
I was hoping you will write that. Please find the files attached.
chrony and VDR still use the init.d scripts. For chrony I have not yet
come around to try the service files [1]. For VDR I started a thread on
all the use cases).
Looking at the `systemd-analyze plot` output I would think PulseAudio
not depending on NetworkManager and GDM3 – maybe start in parallel to
NetworkManager and then wait for network connection – could start
earlier too.
And lastly the mainboard is an ASRock E350M1 (AMD Fusion E-350) and it
is a crucial m4 256 GB SSD [3]. I added the GDM3 service file and
disabled the init.d script motd. Everything else should be a standard
Debian Sid/unstable system.
acpid.service static
Should be pretty much redundant with systemd logind from 185 and newer.
Post by Paul Menzel
checkroot.service static
Should be redundant, done by systemd-fsck-root.service
Post by Paul Menzel
kmod.service static
Should be redundant, done by systemd-modules-load.service, no?
Post by Paul Menzel
module-init-tools.service static
Obsoleted by kmod, no?
Post by Paul Menzel
urandom.service static
Hmm, this is already done by systemd-random-load.service, no?
Post by Paul Menzel
712ms systemd-logind.service
615ms console-kit-log-system-start.service
No need for CK anymore, gdm and friends should support logind just
fine.
Post by Paul Menzel
580ms fglrx-atieventsd.service
540ms chrony.service
515ms rc.local.service
The rc-local generator should be smart enough to pull this in only if it
exists. It's a really slow service and most likely just a NOP anyway.
Post by Paul Menzel
509ms vdr.service
487ms sysfsutils.service
What is this? This stuff sounds like something that can just go away...
Post by Paul Menzel
484ms ssh.service
444ms cron.service
444ms udev.service
407ms systemd-user-sessions.service
360ms media.mount
359ms systemd-remount-api-vfs.service
328ms network-manager.service
328ms dev-mqueue.mount
319ms udev-trigger.service
319ms systemd-modules-load.service
300ms sys-kernel-debug.mount
288ms dev-hugepages.mount
287ms systemd-sysctl.service
256ms sys-kernel-security.mount
239ms networking.service
205ms gdm3.service
195ms hdparm.service
This really should go. It's relly unnecessary these days and if it is
really desired then should be done via a udev rule, not as a
service. (see other discussion on the ML)
Post by Paul Menzel
191ms console-setup.service
Appears to be something that systemd-vconsole-setup should already handle.
Post by Paul Menzel
191ms screen-cleanup.service
Something for tmpfiles?
Post by Paul Menzel
167ms systemd-tmpfiles-setup.service
147ms pulseaudio.service
Hmm, as a system service? Meh..
Post by Paul Menzel
87ms polkitd.service
79ms debian-fixup.service
71ms keyboard-setup.service
Also something systemd-vconsole-setup could do?
Post by Paul Menzel
63ms remount-rootfs.service
44ms console-kit-daemon.service
Again, CK is obsolete.
Post by Paul Menzel
40ms accounts-daemon.service
29ms boot-efi.mount
Hmm, just out of curiosity, what does Debian do here? they automatically
mount the EFI partition to /boot/efi? Is that listed in fstab? Can you
point me to some details on this?
Post by Paul Menzel
28ms upower.service
25ms udisks.service
18ms rtkit-daemon.service
Otherwise looks good!

Lennart
--
Lennart Poettering - Red Hat, Inc.
Michael Biebl
2012-06-27 12:50:35 UTC
Permalink
Hi,
Post by Lennart Poettering
checkroot.service                      static
Should be redundant, done by systemd-fsck-root.service
/lib/systemd/system/checkroot.service -> remount-rootfs.service

This is just a symlink as synchronization point for LSB sysv services.
Post by Lennart Poettering
kmod.service                           static
Should be redundant, done by systemd-modules-load.service, no?
/lib/systemd/system/kmod.service -> systemd-modules-load.service

same here
Post by Lennart Poettering
module-init-tools.service              static
Obsoleted by kmod, no?
/lib/systemd/system/module-init-tools.service -> systemd-modules-load.service

same here
Post by Lennart Poettering
urandom.service                        static
Hmm, this is already done by systemd-random-load.service, no?
/lib/systemd/system/urandom.service -> systemd-random-seed-load.service

same here
Post by Lennart Poettering
   712ms systemd-logind.service
   615ms console-kit-log-system-start.service
No need for CK anymore, gdm and friends should support logind just
fine.
gdm is currently not built with systemd support.

There are quite a few packages which don't support a runtime fallback
for CK, so we decided to stay with CK for wheezy.


Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Michael Biebl
2012-06-27 13:03:19 UTC
Permalink
Post by Michael Biebl
Hi,
Post by Lennart Poettering
checkroot.service                      static
Should be redundant, done by systemd-fsck-root.service
/lib/systemd/system/checkroot.service -> remount-rootfs.service
FWIW, this is with systemd v44, where we don't have a
systemd-fsck-root.service, but fsck-root.service.

IIRC, the sysv checkroot init script also does a remount /, so
symlinking it to remount-rootfs.service seemed like the better fit.

For more info, see also [1] where we mask resp. symlink the sysv
services with native implementations.

Lennart,
if you find anything missing/incorrect in that list, let us know.


Michael

[1] http://git.err.no/cgi-bin/gitweb.cgi?p=systemd;a=blob;f=debian/systemd.links;h=55a7306daadd518d3644e9502e13fe2fafd15a40;hb=refs/heads/debian
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2012-06-27 16:39:12 UTC
Permalink
Post by Michael Biebl
Post by Michael Biebl
Hi,
Post by Lennart Poettering
checkroot.service                      static
Should be redundant, done by systemd-fsck-root.service
/lib/systemd/system/checkroot.service -> remount-rootfs.service
FWIW, this is with systemd v44, where we don't have a
systemd-fsck-root.service, but fsck-root.service.
IIRC, the sysv checkroot init script also does a remount /, so
symlinking it to remount-rootfs.service seemed like the better fit.
For more info, see also [1] where we mask resp. symlink the sysv
services with native implementations.
Lennart,
if you find anything missing/incorrect in that list, let us know.
Michael
[1] http://git.err.no/cgi-bin/gitweb.cgi?p=systemd;a=blob;f=debian/systemd.links;h=55a7306daadd518d3644e9502e13fe2fafd15a40;hb=refs/heads/debian
Ah, this looks actually pretty good (I mean, for what it does). It's
kinda cool that we can do almost all Debian hookups just with a series
of symlinks. Neat!

Lennart
--
Lennart Poettering - Red Hat, Inc
Michael Biebl
2012-06-27 13:28:00 UTC
Permalink
Post by Lennart Poettering
   191ms console-setup.service
    71ms keyboard-setup.service
Also something systemd-vconsole-setup could do?
The Debian systemd package doesn't do a migration of the
console/keyboard configuration yet so if you decide to blacklist those
sysv services you need to set up and manage /etc/vconsole.conf
yourself and you also need to enable systemd-vconsole-setup.service.
The Debian package explicitly removes the symlink from
sysinit.target.wants.


Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2012-06-27 16:41:29 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
   191ms console-setup.service
    71ms keyboard-setup.service
Also something systemd-vconsole-setup could do?
The Debian systemd package doesn't do a migration of the
console/keyboard configuration yet so if you decide to blacklist those
sysv services you need to set up and manage /etc/vconsole.conf
yourself and you also need to enable systemd-vconsole-setup.service.
The Debian package explicitly removes the symlink from
sysinit.target.wants.
Hmm, the other distributions have an #ifdef TARGET_FOOBAR section in
vconsole-setup for that. Debian currently doesn't. I'd be willing to add
a patch that parses the old DEbian configuration files, to implement the
fallback.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Tollef Fog Heen
2012-06-27 19:59:17 UTC
Permalink
]] Lennart Poettering
Post by Lennart Poettering
Hmm, the other distributions have an #ifdef TARGET_FOOBAR section in
vconsole-setup for that. Debian currently doesn't. I'd be willing to add
a patch that parses the old DEbian configuration files, to implement the
fallback.
We use the X11 keyboard definitions. Are you sure you want to
completely reimplement console-setup? :-)
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Lennart Poettering
2012-06-27 20:32:51 UTC
Permalink
Post by Tollef Fog Heen
]] Lennart Poettering
Post by Lennart Poettering
Hmm, the other distributions have an #ifdef TARGET_FOOBAR section in
vconsole-setup for that. Debian currently doesn't. I'd be willing to add
a patch that parses the old DEbian configuration files, to implement the
fallback.
We use the X11 keyboard definitions. Are you sure you want to
completely reimplement console-setup? :-)
Ah, hmm. I heard of that. Can you explain how precisely that works? Do
you actually use the same keybaord definitions, i.e. have converted them
to console definitions? Or do you just share the same naming namespace?

Presumably the console kbd subsystem is much less powerful than X, so i
wonder how this maps.

Any docs available for this?

Honestly this actually sounds a lot better than the non-sense we are
currently doing. This probably something we should just follow debian
in. (and iirc i saw a feature flying by about this for fedora...)

Lennart
--
Lennart Poettering - Red Hat, Inc.
Tollef Fog Heen
2012-06-28 05:54:02 UTC
Permalink
]] Lennart Poettering
Post by Lennart Poettering
Post by Tollef Fog Heen
]] Lennart Poettering
Post by Lennart Poettering
Hmm, the other distributions have an #ifdef TARGET_FOOBAR section in
vconsole-setup for that. Debian currently doesn't. I'd be willing to add
a patch that parses the old DEbian configuration files, to implement the
fallback.
We use the X11 keyboard definitions. Are you sure you want to
completely reimplement console-setup? :-)
Ah, hmm. I heard of that. Can you explain how precisely that works? Do
you actually use the same keybaord definitions, i.e. have converted them
to console definitions? Or do you just share the same naming namespace?
console-setup reads the xkb definitions and downsamples them to
something the console can understand. IIRC, it doesn't work for the
most complex keymaps and the cases where you have multiple keymaps
defined which you can switch between, but it works well in the simple
case of one language. (IIRC, this is due to kernel limitations in how
many keys can be defined and such. Also, I don't think the kernel
understands Compose.)
Post by Lennart Poettering
Any docs available for this?
There might be some in
http://ftp.debian.org/debian/pool/main/c/console-setup/console-setup_1.78.tar.gz
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Paul Menzel
2012-06-28 07:05:42 UTC
Permalink
Post by Tollef Fog Heen
]] Lennart Poettering
Post by Lennart Poettering
Post by Tollef Fog Heen
]] Lennart Poettering
Post by Lennart Poettering
Hmm, the other distributions have an #ifdef TARGET_FOOBAR section in
vconsole-setup for that. Debian currently doesn't. I'd be willing to add
a patch that parses the old DEbian configuration files, to implement the
fallback.
We use the X11 keyboard definitions. Are you sure you want to
completely reimplement console-setup? :-)
Ah, hmm. I heard of that. Can you explain how precisely that works? Do
you actually use the same keybaord definitions, i.e. have converted them
to console definitions? Or do you just share the same naming namespace?
console-setup reads the xkb definitions and downsamples them to
something the console can understand. IIRC, it doesn't work for the
most complex keymaps and the cases where you have multiple keymaps
defined which you can switch between, but it works well in the simple
case of one language. (IIRC, this is due to kernel limitations in how
many keys can be defined and such. Also, I don't think the kernel
understands Compose.)
Post by Lennart Poettering
Any docs available for this?
There might be some in
http://ftp.debian.org/debian/pool/main/c/console-setup/console-setup_1.78.tar.gz
You can also clone the Git repository.

$ debcheckout -d console-setup
type git
url git://git.debian.org/d-i/console-setup.git
top-bases
topgit no


Thanks,

Paul
Lennart Poettering
2012-06-28 11:21:44 UTC
Permalink
On Thu, 28.06.12 07:54, Tollef Fog Heen (***@err.no) wrote:

Heya,
Post by Tollef Fog Heen
Post by Lennart Poettering
Post by Tollef Fog Heen
]] Lennart Poettering
Post by Lennart Poettering
Hmm, the other distributions have an #ifdef TARGET_FOOBAR section in
vconsole-setup for that. Debian currently doesn't. I'd be willing to add
a patch that parses the old DEbian configuration files, to implement the
fallback.
We use the X11 keyboard definitions. Are you sure you want to
completely reimplement console-setup? :-)
Ah, hmm. I heard of that. Can you explain how precisely that works? Do
you actually use the same keybaord definitions, i.e. have converted them
to console definitions? Or do you just share the same naming namespace?
console-setup reads the xkb definitions and downsamples them to
something the console can understand. IIRC, it doesn't work for the
most complex keymaps and the cases where you have multiple keymaps
defined which you can switch between, but it works well in the simple
case of one language. (IIRC, this is due to kernel limitations in how
many keys can be defined and such. Also, I don't think the kernel
understands Compose.)
Ah, pretty cool. I have now added an item to the TODO list, so that we
support this scheme natively in localed and systemd-vconsole-setup. It
appears the much better solution over what we are currently using to
setup the kbd on Fedora.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Colin Guthrie
2012-06-29 01:00:22 UTC
Permalink
Post by Lennart Poettering
Heya,
Post by Tollef Fog Heen
Post by Lennart Poettering
Post by Tollef Fog Heen
]] Lennart Poettering
Post by Lennart Poettering
Hmm, the other distributions have an #ifdef TARGET_FOOBAR section in
vconsole-setup for that. Debian currently doesn't. I'd be willing to add
a patch that parses the old DEbian configuration files, to implement the
fallback.
We use the X11 keyboard definitions. Are you sure you want to
completely reimplement console-setup? :-)
Ah, hmm. I heard of that. Can you explain how precisely that works? Do
you actually use the same keybaord definitions, i.e. have converted them
to console definitions? Or do you just share the same naming namespace?
console-setup reads the xkb definitions and downsamples them to
something the console can understand. IIRC, it doesn't work for the
most complex keymaps and the cases where you have multiple keymaps
defined which you can switch between, but it works well in the simple
case of one language. (IIRC, this is due to kernel limitations in how
many keys can be defined and such. Also, I don't think the kernel
understands Compose.)
Ah, pretty cool. I have now added an item to the TODO list, so that we
support this scheme natively in localed and systemd-vconsole-setup. It
appears the much better solution over what we are currently using to
setup the kbd on Fedora.
Hmm, this reply comes at an interesting time, considering our discussion
recently on IRC :)


FWIW, I finally figured out how we do our keyboards. We keep the
keyboard layout in /etc/sysconfig/keyboard (we use separate vars for X
vs. console). This is then read in via udev rule
/lib/udev/rules.d/61-x11-input.rules which triggers a script which
pushes the xkb variables into the udev database.

I'm not saying it's beautiful, but the principle of pushing the settings
into udev (presumably such that X's evdev can read the settings out from
udev later?) seems like a nice idea. It would allow for a generic config
file that could be used for all keymapping stuff and it begin used for
vconsole and X rather than splitting them over /etc/vconsole.conf and
/etc/X11/xorg.conf.d/00-keyboard.conf.

Although I guess if you want to avoid a shell script being imported into
udev it's likely just a choice between reading/writing a static udev
rule in /etc or the xorg.conf snippet, in which case both are much of a
muchness (unless Wayland also uses these udev keys in which case the
udev approach is arguably better).


Here's the files for reference:

61-x11-input.rules:
SUBSYSTEM!="input", GOTO="x11_input_end"
ACTION!="add", GOTO="x11_input_end"
KERNEL!="event*", GOTO="x11_input_end"

ENV{ID_INPUT_KEY}=="1", IMPORT{program}="/sbin/mageia-setup-keyboard --udev"

LABEL="x11_input_end"



mageia-setup-keyboard:

#!/bin/sh
#
# Trivial egregious hack to load the console keyboard layout into XKB.
#

. /etc/sysconfig/keyboard > /dev/null 2> /dev/null || exit 0

if [ -z "$XkbLayout" ]; then
[ -x /usr/sbin/keyboarddrake ] || exit 0
/usr/sbin/keyboarddrake --migrate
. /etc/sysconfig/keyboard
fi

[ -n "$XkbLayout" ] || exit 0

if [ "$1" = "--udev" ]; then
[ -z "$XkbModel" ] || echo "xkbmodel=$XkbModel"
[ -z "$XkbLayout" ] || echo "xkblayout=$XkbLayout"
[ -z "$XkbVariant" ] || echo "xkbvariant=$XkbVariant"
[ -z "$XkbOptions" ] || echo "xkboptions=$XkbOptions"
else
# We're being called stand-alone
# This will only work if we're root
[ -x /sbin/udevadm ] && /sbin/udevadm trigger
--subsystem-match=input --action=add
fi
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Paul Menzel
2012-06-30 11:47:15 UTC
Permalink
[
]
Post by Lennart Poettering
Post by Paul Menzel
540ms chrony.service
515ms rc.local.service
The rc-local generator should be smart enough to pull this in only if it
exists. It's a really slow service and most likely just a NOP anyway.
Right. The default file `/etc/rc.local` just contains `exit 0`. So I
masked that service file.

$ sudo systemctl mask rc.local.service
Post by Lennart Poettering
Post by Paul Menzel
509ms vdr.service
487ms sysfsutils.service
What is this? This stuff sounds like something that can just go away...
I was surprised too. It looks like this was installed by
`grml-debootstrap` and I removed it using the following command.

$ sudo aptitude purge --purge-unused sysfsutils

[
]
Post by Lennart Poettering
Post by Paul Menzel
191ms screen-cleanup.service
Something for tmpfiles?
I have to look into that.
Post by Lennart Poettering
Post by Paul Menzel
167ms systemd-tmpfiles-setup.service
147ms pulseaudio.service
Hmm, as a system service? Meh..
Well, no. Debian still ships an init.d script which reads
`/etc/default/pulseaudio` and there system mode is disabled by default.
So I masked this one too.

$ sudo systemctl mask pulseaudio.service

[
]


Thanks,

Paul
Lennart Poettering
2012-07-03 00:26:55 UTC
Permalink
Post by Paul Menzel
Post by Lennart Poettering
Post by Paul Menzel
509ms vdr.service
487ms sysfsutils.service
What is this? This stuff sounds like something that can just go away...
I was surprised too. It looks like this was installed by
`grml-debootstrap` and I removed it using the following command.
$ sudo aptitude purge --purge-unused sysfsutils
I pretty sure this is a package to remove from the distribution
entirely.
Post by Paul Menzel
Post by Lennart Poettering
Hmm, as a system service? Meh..
Well, no. Debian still ships an init.d script which reads
`/etc/default/pulseaudio` and there system mode is disabled by default.
So I masked this one too.
$ sudo systemctl mask pulseaudio.service
Hmm, dounds a bit strange that on Debian you enable/disable that script
via a file in /etc/default, even though sysv already has a mechanism for
this, which is the done by update-rcd, right? Sounds like two levels of
turning things off where one would be sufficient and less confusing...

Lennart
--
Lennart Poettering - Red Hat, Inc.
Michael Biebl
2012-07-03 01:09:29 UTC
Permalink
Post by Lennart Poettering
Post by Paul Menzel
Well, no. Debian still ships an init.d script which reads
`/etc/default/pulseaudio` and there system mode is disabled by default.
So I masked this one too.
$ sudo systemctl mask pulseaudio.service
Hmm, dounds a bit strange that on Debian you enable/disable that script
via a file in /etc/default, even though sysv already has a mechanism for
this, which is the done by update-rcd, right? Sounds like two levels of
turning things off where one would be sufficient and less confusing...
Those /etc/default/<foo> files with ENABLE/DISABLE switches are a plague.

http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/2007-June/000461.html
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Colin Guthrie
2012-07-03 09:37:25 UTC
Permalink
Post by Lennart Poettering
Post by Paul Menzel
Post by Lennart Poettering
Post by Paul Menzel
509ms vdr.service
487ms sysfsutils.service
What is this? This stuff sounds like something that can just go away...
I was surprised too. It looks like this was installed by
`grml-debootstrap` and I removed it using the following command.
$ sudo aptitude purge --purge-unused sysfsutils
I pretty sure this is a package to remove from the distribution
entirely.
Post by Paul Menzel
Post by Lennart Poettering
Hmm, as a system service? Meh..
Well, no. Debian still ships an init.d script which reads
`/etc/default/pulseaudio` and there system mode is disabled by default.
So I masked this one too.
$ sudo systemctl mask pulseaudio.service
Hmm, dounds a bit strange that on Debian you enable/disable that script
via a file in /etc/default, even though sysv already has a mechanism for
this, which is the done by update-rcd, right? Sounds like two levels of
turning things off where one would be sufficient and less confusing...
Maybe it's just a protection against users own lack of knowledge. e.g.
if they see a pulseaudio service and think "hey I use pulseaudio, this
should be enabled" and then enable it, they will suddenly find
themselves switched to pulseaudio system-wide mode (not generally
recommended) rather than pulseaudio per-user mode (recommended).

Just a guess, but I'd personally say that if you are going to ship an
initscript for PA at all (I try to avoid it) then just include it in a
separate sub-package.

Speaking of which... assuming a time when systemd user sessions are the
norm, can a system service conflict with a user service? e.g. say we had
pulseaudio.service active (thus a system-wide instance), it should
really conflict with the user pulseaudio.service... Anyway way to
achieve that? Might be a bit of a strange use case to be honest.

Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Paul Menzel
2012-06-30 12:43:44 UTC
Permalink
Am Mittwoch, den 27.06.2012, 12:35 +0200 schrieb Lennart Poettering:

[
]
Post by Lennart Poettering
Post by Paul Menzel
29ms boot-efi.mount
Hmm, just out of curiosity, what does Debian do here? they automatically
mount the EFI partition to /boot/efi? Is that listed in fstab? Can you
point me to some details on this?
It is listed in `/etc/fstab`.

/dev/sda3 /boot/efi vfat defaults 0 2

Since I did not find any official information regarding Debian and UEFI
I followed the blog post from Tanguy Ortolo [1] which states to put that
entry into `/etc/fstab`. Although I think it still does not work since
`efibootmgr` does not work.


Thanks,

Paul


[1] http://tanguy.ortolo.eu/blog/article51/debian-efi
Lennart Poettering
2012-06-25 13:38:15 UTC
Permalink
Post by Paul Menzel
Dear systemd folks,
how can I disable init.d scripts which systemd loads for compatibility
reasons?
$ ls /etc/init.d/motd (or any other init.d script)
/etc/init.d/motd
$ systemd-analyze blame | grep motd
543ms motd.service
$ sudo systemctl disable motd.service
Failed to issue method call: No such file or directory
On Fedora we defer to chkconfig automatically for sysv services. This
hookup is currently missing for Debian, but I'd be willing to merge a
patch for that.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Paul Menzel
2012-06-25 19:33:21 UTC
Permalink
[
]
Post by Lennart Poettering
Post by Paul Menzel
how can I disable init.d scripts which systemd loads for compatibility
reasons?
$ ls /etc/init.d/motd (or any other init.d script)
/etc/init.d/motd
$ systemd-analyze blame | grep motd
543ms motd.service
$ sudo systemctl disable motd.service
Failed to issue method call: No such file or directory
On Fedora we defer to chkconfig automatically for sysv services.
Looking at the code

$ git grep -i chkconfig

this seems to happen for the following distributions.

#if defined (HAVE_SYSV_COMPAT) && (defined(TARGET_FEDORA) || defined(TARGET_MANDRIVA) || defined(TARGET_SUSE) || defined(TARGET_MEEGO) || defined(TARGET_ALTLINUX) || defined(TARGET_MAGEIA))
Post by Lennart Poettering
This hookup is currently missing for Debian, but I'd be willing to merge a
patch for that.
If I am not mistaken, Debian uses `update-rc.d` for that purpose.

Does someone know if it is feasible to just change the one variable (and
options) containing the path to the utilities and reuse the error
handling or will that not work?


Thanks,

Paul
Lennart Poettering
2012-06-27 09:13:54 UTC
Permalink
Post by Paul Menzel
Post by Lennart Poettering
This hookup is currently missing for Debian, but I'd be willing to merge a
patch for that.
If I am not mistaken, Debian uses `update-rc.d` for that purpose.
Does someone know if it is feasible to just change the one variable (and
options) containing the path to the utilities and reuse the error
handling or will that not work?
I'd be careful. While the code for update-rc.d would probably look very
similar, you'd need to make sure that the error codes returned by
update-rc.d match, and you handle stuff such as --root= and things like
that.

The patch shouldn't be hard, but needs some care to be taken.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Continue reading on narkive:
Loading...