On Fri, Jun 7, 2013 at 3:18 AM, Иван Шаповалов <intelfx...@gmail.com> wrote: > Hi all, > > Recently I've attempted to switch my user session to "systemd --user". The > configuration is pretty simple - no multiseat, nothing special. > I start the user session with provided "user@.service" with some > modifications: > > --- /usr/lib/systemd/system/user@.service 2013-05-30 16:55:28.000000000 > +0400 > +++ /etc/systemd/system/user@.service 2013-06-07 03:46:27.158435556 +0400 > @@ -13,11 +13,14 @@ > User=%I > PAMName=systemd-shared > # in order to allow MEM_CG features to work, add "memory:/" here > -ControlGroup=%R/user/%U.user/shared cpu:/ > +# note to myself: cpu:/ has been removed due to running a -ck kernel > +ControlGroup=%R/user/%U.user/shared > ControlGroupModify=yes > Type=notify > ExecStart=-/usr/lib/systemd/systemd --user > +Environment=XDG_RUNTIME_DIR=/run/user/%U > > Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bus_socket > +Environment=SHELL=%s > > [Install] > Alias=user@%i.service > -- > > This modified unit works (almost) as expected, however, everything that is > started under that systemd instance does _not_ get its own session. > For example, $XDG_SESSION_ID is empty and there are no new records > in output of 'loginctl list-sessions'. > > So, a question: is this the desired behavior, and, if yes, how can I create > a session manually?
This is one of the missing parts - loginctl needs modifications to make enable-linger working, and that's not implemented. Ultimately, the admin should not directly start a user@.service instance manually. Auke _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel