[SOLVED] systemd: Cannot run systemd-run --scope as user after 233-6

alive4ever · 2017-07-04 17:28:04

After upgrading to 233-6, I can no longer run tmux from systemd-run. This works before (232-something)

systemd-run --scope --user tmux

systemd-run --scope --user tmux
Job for run-r23acdbe580484da0a18cc26e940c29b0.scope failed.
See "systemctl status run-r23acdbe580484da0a18cc26e940c29b0.scope" and "journalctl -xe" for details.

Jul 05 00:23:12 alive-pc systemd[424]: run-r23acdbe580484da0a18cc26e940c29b0.scope: Failed to add PIDs to scope's control group: Permission denied
Jul 05 00:23:12 alive-pc systemd[424]: Failed to start /usr/bin/tmux.
-- Subject: Unit UNIT has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit UNIT has failed.
-- 
-- The result is failed.
Jul 05 00:23:12 alive-pc systemd[424]: run-r23acdbe580484da0a18cc26e940c29b0.scope: Unit entered failed state.

Is this related to this issue?
Any hint appreciated.

EDIT: Workaround required. Read this post.

Last edited by alive4ever (2017-07-13 13:13:29)

alive4ever · 2017-07-04 17:39:09

This problem still present with systemd 233-7

alive4ever · 2017-07-09 03:00:57

This problem still persist on 233.75-3

Someone brought this issue to the list with no clear solution.

Any hint is appreciated.

lamarpavel · 2017-07-12 09:18:39

I am observing something similar, not the exact same but with enough similarities to suggest the same underlying problem. Since updating (from 232-8 to 233.75-3) the timers started with

systemctl --user enable something.timer

terminate when I log out from the SSH session, even though I have not set KillUserProcesses in /etc/systemd/logind.conf. There is a tmux session that I started manually after logging in and that I can detach and re-attach to between SSH sessions. So processes not started as user unit survive between sessions.
I noticed the behaviour since one of the timers is supposed to run a backup service every few hours but instead runs with every login now, blocking the login for several seconds.

alive4ever · 2017-07-13 13:09:19

Ok, it seems that the distro package maintainer enabled systemd hybrid cgroup without kernel support.

For now, I can get systemd-run --user --scope tmux to run with additional kernel parameter below.

systemd.legacy_systemd_cgroup_controller=true

For those who experience the same issue, the temporary workaround is to add the kernel parameter above.

For grub boot loader, make the following modification on /etc/default/grub and regenerate the boot entry via grub-mkconfig.

GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.legacy_systemd_cgroup_controller=true"

Thanks to David Runge for providing the hint.

For now, I'll mark this thread as solved and open a new bug report regarding hybrid cgroup enablement without kernel support.

alive4ever · 2017-07-13 13:27:58

Here is the available hirearchy for systemd cgroup, which is needed to be enabled during compile time.

AC_ARG_WITH(default-hierarchy,
        AS_HELP_STRING([--with-default-hierarchy=MODE],
                [default cgroup hierarchy, defaults to "hybrid"]),
        [DEFAULT_HIERARCHY="$withval"],
        [DEFAULT_HIERARCHY="hybrid"])

AS_CASE("$DEFAULT_HIERARCHY",
        [legacy], [mode=CGROUP_UNIFIED_NONE],
        [hybrid], [mode=CGROUP_UNIFIED_SYSTEMD],
        [unified], [mode=CGROUP_UNIFIED_ALL],
        AC_MSG_ERROR(Bad default hierarchy mode ${DEFAULT_HIERARCHY}))
AC_DEFINE_UNQUOTED(DEFAULT_HIERARCHY, [$mode], [Default cgroup hierarchy])
AC_DEFINE_UNQUOTED(DEFAULT_HIERARCHY_NAME, ["$DEFAULT_HIERARCHY"],
[Default cgroup hierarchy as string])

Without explicitly setting the default hierarchy, hybrid is selected and causes systemd-run --user --scope to break.

lamarpavel · 2017-07-14 09:38:09

This kernel parameter fixes my issue as well, thank you!

Can I find out when/if the official package is fixed just by looking at the package? I'd like to run such a test during login so I get a reminder to remove the kernel param once its no longer needed.

Again, thanks a lot for putting in the effort.

alive4ever · 2017-07-14 13:41:02

lamarpavel wrote:

This kernel parameter fixes my issue as well, thank you!
Can I find out when/if the official package is fixed just by looking at the package? I'd like to run such a test during login so I get a reminder to remove the kernel param once its no longer needed.
Again, thanks a lot for putting in the effort.

Viewing systemd compile time definition can be achieved via this command.

$ systemctl --version
systemd 233             
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN default-hierarchy=hybrid

The hybrid default hierarchy is currently problematic, so that the cgroup issue occurs.

I think legacy should be used as default cgroup-hierarchy during compile time.

You may try removing boot parameter when either systemd or kernel package is upgraded and see what happens.

graysky · 2017-07-14 14:21:24

See the release notes wherein "hybrid" is the recommended option: https://lists.freedesktop.org/archives/ … 38419.html

Arch Linux

#1 2017-07-04 17:28:04

[SOLVED] systemd: Cannot run systemd-run --scope as user after 233-6

#2 2017-07-04 17:39:09

Re: [SOLVED] systemd: Cannot run systemd-run --scope as user after 233-6

#3 2017-07-09 03:00:57

Re: [SOLVED] systemd: Cannot run systemd-run --scope as user after 233-6

#4 2017-07-12 09:18:39

Re: [SOLVED] systemd: Cannot run systemd-run --scope as user after 233-6

#5 2017-07-13 13:09:19

Re: [SOLVED] systemd: Cannot run systemd-run --scope as user after 233-6

#6 2017-07-13 13:27:58

Re: [SOLVED] systemd: Cannot run systemd-run --scope as user after 233-6

#7 2017-07-14 09:38:09

Re: [SOLVED] systemd: Cannot run systemd-run --scope as user after 233-6

#8 2017-07-14 13:41:02

Re: [SOLVED] systemd: Cannot run systemd-run --scope as user after 233-6

#9 2017-07-14 14:21:24

Re: [SOLVED] systemd: Cannot run systemd-run --scope as user after 233-6

Board footer