Survey on systemd Who uses it?

[ralul]

Today in experimental systemd-204 arrived.
Someone trying
I'll wait 4 days ...

[devil]

runs for about 6 hours ithout problems

greetz
devil

[dibl]

On my main productivity system, a big desktop rig with 2 SSDs and 2 hdds, with Nvidia proprietary driver, the new systemd boots to the KDE login in 14 seconds -- very impressive!  Shutdown/restart is now working as expected.

[vilde]

Today in experimental systemd-204 arrived.
Someone trying
I'll wait 4 days ...

ok, I want to give systemd a try again with the new version.

@ ralul, on some post you wrote something about a wrong configured systemd or something like that (in the content about switching to level 3 for doing d-u, if I don't remember wrong).

So whats the right way to install and also maybe configure systemd?

[ralul]

@vilde, as I hardly remember this was a long time ago and an issue with sysvinit-compat. Using a newer version and switching to level 3, witch is:
systemctl isolate multi-user.target

should be without problems. But who knows what differentiated compat mechanism will be further developed by Debian maintainers ...

If you want no hassle wait until a new systemd arrives in Debian sid!

On the safe side:
- You can (e)nter the grub line and add: systemd.unit=rescue.target
- You probably are able to boot using the old sysvinit as a last resort.

And pay attention when using:
LVM2 or cryptsetup or a separate /usr partition! Dracut as a mechanism to create an initrd is specially developed to work with systemd. For example openSUSE has had a very efficient distribution specific "mkinitrd" but is now changing to Dracut also. This has reason!!!

As a first step on the way to systemd I would try to boot an extra grub2 entry with a dracut created initrd. At of this moment Debian sid has dracut-027 (which should be fine with systemd-204).

I hope even better will be:

dracut-29
(released upstream - much lvm and cryptsetup work)

systemd-206
(not released upstream - many cgroup changes will finish demanded kernel.org changes. Systemd-205 was half baked in that regard. These cgroup things are important to manage virtual machines on big servers.)

[timc]

So whats the right way to install and also maybe configure systemd?

This is the way I am doing it. If it is incorrect, someone please give further advice.

Code Auswählen Erweitern

apt-get -t experimental install systemd libpam-systemd systemd-sysv

echo "systemd-sysv hold" | dpkg --set-selections

Also, note that not all services are necessarily enabled, cleanly. You may have to do something such as:

Code Auswählen Erweitern

systemctl.enable ntp
to get a particular service started via systemd.

Tim

[dibl]

Code Auswählen Erweitern

apt-get -t experimental install systemd libpam-systemd systemd-sysv

That's exactly how I've been installing it -- no problems so far on 6 systems.

Code Auswählen Erweitern


echo "systemd-sysv hold" | dpkg --set-selections

You only need to do this once.  If you previously installed ver. 44-12 and set it to "hold", installing the new version from experimental will change the installed version of systemd-sysv, but it will not change the dpkg status -- it remains a "hold".

Also, note that not all services are necessarily enabled, cleanly. You may have to do something such as:

Code Auswählen Erweitern

systemctl.enable ntp
to get a particular service started via systemd.

Tim

As far as I can see, you can simply

Code Auswählen Erweitern

service samba stop

or

Code Auswählen Erweitern

service samba start

check it with

Code Auswählen Erweitern

service samba status

I have not needed to do any special configurations at all, to run samba, vmware, and typical ethernet and wireless networking.

[ralul]

@dibl, service is a wrapper that might well point to the actual init system.

systemctl stop Foobar
=
service Foobar stop

systemctl enable Foobar
does activate Foobar for the next startsequence.
It  simply symlinks in a target. You can also:

mkdir -p /etc/systemd/system/graphical.target.wants
ln -s /usr/lib/systemd/system/Foobar.service \
     /etc/systemd/system/graphical.target.wants

[dibl]

Thanks @ralul -- good to know.

Looking forward to the day of a new (future) Debian installation with only systemd, I suppose it will be important to understand this, as the remains of the legacy init system will be gone.

[ralul]

experimental systemd-204-1
is just a blind shot without Debian specific adaption, the maintainer himself:

Hardware and udev related:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717405

From: Michael Biebl <biebl>
To: Debian Bug Tracking System <submit>
Subject: 50-udev-default.rules: Fails to tag devices with hwdb meta data
Date: Sat, 20 Jul 2013 14:34:56 +0200
Package: udev
Version: 204-1
Severity: normal

Since we are using the custom 50-udev-default.rules file from the old
udev package, we currently dont properly tag devices with the hwdb meta
data.

The upstream 50-udev-default.rules has
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"
SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{builtin}="input_id"
ENV{MODALIAS}!="", IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"

We should consider replacing our custom 50-udev-default.rules and
91-permissions.rules with the upstream 50-udev-default.rules file.

If there modifications worth keeping, we should try to get them upstream
or maintain them as a minimal patch.

Initramfs related:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717429

Am 20.07.2013 21:51, schrieb Josh Triplett:
> Package: systemd
> Version: 204-1
> Severity: wishlist
>
> systemd supports running from within the initramfs, and it adds various
> features when doing so, such as timing support, or cleaner support for
> encrypted filesystems.  Please consider making use of this.

Most likely the wrong component. As you said, systemd supports being run
from the initramfs. This most likely needs to be integrated into
initramfs-tools directly. I don't think the hooks support in
intramfs-tools is flexible enough that this can be done with a few hooks
provided by systemd.

I understand your wish, but this is not something which can be solved in
the systemd package afaics.

Michael

Michael later answers:

Code Auswählen Erweitern

Latest dracut releases have support
/ are designed to run systemd in the initramfs.

If initramfs-tools can be changed to utilize systemd, I honestly don't know.

Journal releated:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717386

From: Michael Stapelberg <stapelberg>
To: Josh Triplett <josh>, 717386@bugs.debian.org, Sven Joachim <svenjoac>
Subject: Re: [Pkg-systemd-maintainers] Bug#717386: systemd-journal group does not exist
Date: Sat, 20 Jul 2013 11:37:43 +0200
Hi,

Josh Triplett <josh> writes:
>> > However, systemd does not create this group.
>>
>> As a result, journalctl doesn't work:
>>
>> ,----
>> | $ journalctl                          
>> | Hint: You are currently not seeing messages from other users and the system.
>> |       Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice.
>> | No journal files were opened due to insufficient permissions.
>> `----
I am not sure I buy "journalctl doesn't work". It works as intended, you just don't have the nice feature of being in a special group to get more
read access than you currently have. journalctl per se does work, e.g. as root.
> ...
Thanks for creating a bug report to track this, it was planned from our side to do this (but after the upload). I see three action items here:

1. (bug #717386) Create the systemd-journal group
2. (bug #717388) Ensure systemd-journal and adm have read access to /var/log/journal
3. (bug #717388) Patch the message in journalctl to make users aware of the adm group.

[GoinEasy9]

I'm doing well with systemd 204-2.  It has solved the reboot problem.  Journalctl is also working with whatever I throw at it.  Just some observations.  

journald.conf is at /etc/systemd/journald.conf, not, /etc/systemd/systemd-journald.conf.  Maybe this changed in the most recent version?

I'm seeing this during boot:
root@siduction64kdeFX:/home/goineasy9# journalctl -b | grep systemd-modules-load.service
Aug 02 22:35:45 siduction64kdeFX systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
Aug 02 22:35:45 siduction64kdeFX systemd[1]: Unit systemd-modules-load.service entered failed state.
Aug 02 22:35:49 siduction64kdeFX systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
Aug 02 22:35:49 siduction64kdeFX systemd[1]: Unit systemd-modules-load.service entered failed state.

If you look at /lib/systemd/system/systemd-modules-load.service it looks for /usr/local/lib/modules-load.d, and, theres no such folder.  The same goes for /run/modules-load.d.  This may be the cause of the boot error, but, I haven't looked into it further.

Anyway, so far so good, only time will tell.

[ralul]

/etc/systemd/journald.conf, not, /etc/systemd/systemd-journald.conf.  Maybe this changed in the most recent version?

Yes, name change to simplyfy all journal related ...

...
Aug 02 22:35:49 siduction64kdeFX systemd[1]: Unit systemd-modules-load.service entered failed state.

If you look at /lib/systemd/system/systemd-modules-load.service it looks for /usr/local/lib/modules-load.d, and, theres no such folder.  The same goes for /run/modules-load.d.  This may be the cause of the boot error

No, this shouldn't result in a failed state, as in the service unit it is an OR condition:

Code Auswählen Erweitern

ConditionDirectoryNotEmpty=|/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/local/lib/modules-load.d
ConditionDirectoryNotEmpty=|/etc/modules-load.d
ConditionDirectoryNotEmpty=|/run/modules-load.d
Can you verify my assumption by simply creating the missing directories?
Or, you could copy the unit file into
/etc/systemd/system/systemd-modules-load.service
and edit: deleting all lines with directories you don't have. Your personal edited unit should have precedence. (Don't forget to delete this file later on to follow upstream when upgrading)

You then could compare log output:
journalctl -b -1
journalctl -b

By the way, the most kernel modules do have appropriate udev rules nowadays, no moules-load needed any more ....

[edit]Ich habe gerade Systemd-204-2 auf Debian ausprobiert:
journalctl -b -1
geht erst ab systemd-206 - also noch nicht Debian sid

[dibl]

I discovered today that systemd does not create the user-writeable /run/shm directory, which init does create.

A bug report was filed, but closed with no action -- the maintainer does not consider this to be a bug.

It's only important to know if you were thinking of using /run/shm for something.

[vilde]

How far away are systemd, next release?

[devil]

Not sure yet, not too much sincere testing has happened. also we need to be able to fully support it.

greetz
devil