# >=systemd-205 und cgroups

## franzf

Hej,

Hier schnell der Link zum release announcement:

http://lists.freedesktop.org/archives/systemd-devel/2013-July/011679.html

Darin steht knapp:

 *Quote:*   

> Slices and scopes have been introduced primarily in
> 
>           context of the work to move cgroup handling to a
> 
>           single-writer scheme, where only PID 1
> ...

 

Und da scheint aktuell bei mir ein Problem zu bestehen. systemd --user lässt sich nicht mehr starten:

```
 $ systemd --user

Failed to create root cgroup hierarchy: Permission denied

Failed to allocate manager object: Permission denied
```

Hintergrund: Ich würde gerne offlineimap als systemd-service starten, nachdem sich mein user eingeloggt hat. Das klapp jetzt natürlich nicht...

Ich hab schon angefangen, mich durch (mMn.) passende manpages zu hangeln, aber eine Info darüber, was los ist, hab ich nicht bekommen  :Sad: 

strace sagt:

```

lstat("/sys/fs/cgroup", {st_mode=S_IFDIR|0755, st_size=160, ...}) = 0

lstat("/sys/fs", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0

access("/sys/fs/cgroup/systemd", F_OK)  = 0

stat("/sys/fs/cgroup/systemd/user.slice/user-1001.slice", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0

mkdir("/sys/fs/cgroup/systemd/user.slice/user-1001.slice/session-c1.scope", 0755) = -1 EEXIST (File exists)

access("/sys/fs/cgroup/systemd", F_OK)  = 0

open("/sys/fs/cgroup/systemd/user.slice/user-1001.slice/session-c1.scope/cgroup.procs", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)

writev(2, [{"\33[1;31m", 7}, {"Failed to create root cgroup hie"..., 57}, {"\33[0m", 4}, {"\n", 1}], 4Failed to create root cgroup hierarchy: Permission denied

) = 69

lstat("/sys/fs/cgroup/systemd/user.slice/user-1001.slice/session-c1.scope", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0

openat(AT_FDCWD, "/sys/fs/cgroup/systemd/user.slice/user-1001.slice/session-c1.scope", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5

getdents(5, /* 7 entries */, 32768)     = 240

newfstatat(5, "cgroup.clone_children", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0

newfstatat(5, "cgroup.event_control", {st_mode=S_IFREG|0222, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0

newfstatat(5, "notify_on_release", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0

newfstatat(5, "cgroup.procs", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0

newfstatat(5, "tasks", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0

getdents(5, /* 0 entries */, 32768)     = 0

close(5)                                = 0

close(3)                                = 0

close(4)                                = 0

close(0)                                = 0

writev(2, [{"\33[1;31m", 7}, {"Failed to allocate manager objec"..., 52}, {"\33[0m", 4}, {"\n", 1}], 4Failed to allocate manager object: Permission denied

) = 64

exit_group(1)                           = ?

+++ exited with 1 +++
```

Hat jemand Infos dazu?

Welche Infos braucht ihr, um mir weiterhelfen zu können?

----------

## schmidicom

systemd-205 scheint was die cgroups angeht etwas bugy zu sein. Bei mir startete es zwar aber dafür gabs beim herunterfahren Probleme.

Nimm die die Version 206, die funktioniert.Last edited by schmidicom on Sat Jul 27, 2013 11:54 am; edited 1 time in total

----------

## franzf

 *schmidicom wrote:*   

> systemd-205 scheint was die cgroups angeht etwas buggy. Bei mir startete es zwar aber dafür gabs beim herunterfahren Probleme.
> 
> Nimm die die Version 206, die funktioniert.

 

Aha, danke!

Installiert ist es seit 23. Juli, nur hab ich seit 20 Tagen nicht neu gestartet. Guter Zeitpunkt, ein Feauture auszutesten:

Ich hab gelesen, dass man den systemd-daemon im laufenden Betrieb neustarten kann, man also nach Aktualisierung nicht rebooten muss.

Wie geht das? (Ich werd später trotzdem neustarten -> kernel update - aber nur der Interesse halber)

----------

## franzf

Ich hab jetzt einfach (mit systemd-206 und gentoo-sources-3.10.3-r1) neugestartet.

Das ursprüngliche Problem ist leider nicht behoben.

----------

## schmidicom

Bei mir kommt die selbe Fehlermeldung, schade denn das wäre wirklich eine interessante Funktion.

----------

## franzf

downgrade auf systemd-204 und alles geht wie es soll - offlineimap wird beim Login gestartet  :Smile: 

Ich werd dann mal nen bugreport aufmachen.

https://bugs.gentoo.org/show_bug.cgi?id=478358

----------

## schmidicom

Wenn man darauf angewiesen ist dann ist ein downgrade vermutlich sinnvoll aber ich kann warten bis ein fix kommt.

Das ganze könnte sogar den autostart von xdg ersetzen und KDE dabei helfen seine eigenen Dienste besser zu verwalten, wenn es dann mal fehlerfrei funktioniert.  :Wink: 

----------

## franzf

 *schmidicom wrote:*   

> Wenn man darauf angewiesen ist dann ist ein downgrade vermutlich sinnvoll aber ich kann warten bis ein fix kommt.

 

Darauf angewiesen bin ich nicht (unbedingt) - ist halt bequem  :Smile:  Ansonsten würde ich das anders regeln. Da ich nicht wirklich weiß, ob ich unbedingt die features aus systemd >204 brauche, bin ich mit dem downgrade zufrieden.

Allerdings (Gschmäckle...) wundert es mich, dass ein zentrales feature kaputt geht und keiner hat's gemerkt - für sowas sollte es automatisierte Tests geben. Evtl. ist es auch nur ein Konfigurationsproblem - abwarten was der Bugreport macht.

----------

## schmidicom

Das mit dem Bugreport scheint aber nicht so gut zu laufen?

----------

## franzf

 *schmidicom wrote:*   

> Das mit dem Bugreport scheint aber nicht so gut zu laufen?

 

Jepp :/

Kurz: systemd --user selber starten ist nicht mehr ab 205. Dafür soll man user@.service aktivieren, der startet dann einen systemd --user per user. Hab ich gemacht, einen user-systemd hab ich nicht bekommen. Damit geht auch systemctl --user nicht. Sollte aber.

Bis das Problem behoben ist werde ich mir eine Lösung basteln, die unabhängig vom init-system funktioniert.

https://bugs.freedesktop.org/show_bug.cgi?id=67471

http://lists.freedesktop.org/archives/systemd-devel/2013-July/012354.html

----------

## schmidicom

 *franzf wrote:*   

> Bis das Problem behoben ist werde ich mir eine Lösung basteln, die unabhängig vom init-system funktioniert.

 

Ich habe aber nicht den Eindruck als ob bei den systemd-devs all zuviel Interesse daran besteht diesen Bug (user@.service) zu fixen.

----------

## franzf

 *schmidicom wrote:*   

>  *franzf wrote:*   Bis das Problem behoben ist werde ich mir eine Lösung basteln, die unabhängig vom init-system funktioniert. 
> 
> Ich habe aber nicht den Eindruck als ob bei den systemd-devs all zuviel Interesse daran besteht diesen Bug (user@.service) zu fixen.

 

Ich weiß ja nicht einmal ob es wirklich ein bug ist. Könnte ein Config-Problem sein. Oder es fehlen irgenwelche Voraussetzungen (kernel config, runtime dep, ... mehr als mich auf die ebuilds verlassen kann ich ja nicht) Aber scheinbar weiß das selbst von den DEVs niemand so genau, oder will es nicht sagen (oder meint ich bin ein Troll...).

----------

## schmidicom

Also ich kann user@.service auch nicht starten.

Als "root" mach ich das:

```
slap ~ # systemctl start user@schmidicom.service

slap ~ # systemctl status user@schmidicom.service

user@schmidicom.service - User Manager for schmidicom

   Loaded: loaded (/usr/lib64/systemd/system/user@.service; static)

   Active: inactive (dead)

Aug 05 11:43:47 slap systemd[1]: Starting User Manager for schmidicom...

Aug 05 11:43:47 slap systemd[1]: Started User Manager for schmidicom.
```

Und als "schmidicom" kommt dann das:

```
schmidicom@slap ~ $ systemctl --user

Failed to issue method call: Process /bin/false exited with status 1
```

Und gemäß  "ps -A" ist nur ein systemd am laufen, der erste, also gehe ich davon aus das er nicht läuft.

----------

## franzf

Kurzes update:

Bin zurück zu openrc. systemd hatte ich ja nur installiert, weil mit kde das powermanagement nicht korrekt funktioniert hat (falsches power profile).

Zu dem Problem hier, dass sich upstream nicht wirklich um eine Lösung/Hilfestellung bemüht, kommt noch erschwerend, dass ich Probleme beim shutdown hab: Einerseits gibt es immer Meldungen, dass ein dbus-interface nicht mehr verfügbar ist (org.freedesktop.systemd war das FAIR), andererseits brauchen >50% der shutdowns >5 Minuten (genau sagen kann ich es nicht, ich geh dann immer andere Sachen machen), der Rest braucht ~30 Sekunden (zu dem Zeitpunkt steht eine journald-Meldung - vielleicht synct der grad seine Messages oder was weiß ich).

Die Lösung, die ich für offlineimap gewählt habe, ist durchaus simpel:

```
foip:3:respawn:/usr/bin/sudo -u franz /usr/bin/offlineimap -u basic -l /home/franz/.log/offlineimap > /dev/null
```

Am Ende meiner inittab. Eine ähnliche Lösung wäre sicher auch mit systemd möglich gewesen, aber dafür ist es jetzt zu spät  :Wink: 

----------

