xpra icon
Bug tracker and wiki

Opened 8 days ago

Closed 7 days ago

Last modified 7 days ago

#2585 closed defect (fixed)

Systemd cgroups ticket back at it again

Reported by: Tmanok Owned by: Tmanok
Priority: critical Milestone: 4.0
Component: server Version: 3.0.x
Keywords: systemd, fresh-install Cc:

Description (last modified by Antoine Martin)

Hello XPRA Devs,

You all make a most excellent application, I use it daily as of this past month and used to use it long ago. There was a bug that plagued XPRA for about 2 years it seemed and it related to systemd changes. This month I have noticed this problem on every fresh install (from your APT repository) on over 10 devices just this week alone. My platforms are Ubuntu, Debian, LinuxMint, (and HeliumBL actually). My installation process is simple:

  1. sudo apt update ; sudo apt install apt-transport-https
  2. wget -q https://xpra.org/gpg.asc -O- | sudo apt-key add -
  3. sudo add-apt-repository "deb https://xpra.org/ bionic main"
  4. sudo apt update ; sudo apt install xpra
  5. xpra --version

(Should be 3.0.5 or greater in 2020.)

  1. xpra start :100 --start=/usr/bin/firefox

But then this happens:

using systemd-run to wrap 'start' server command
'systemd-run' '--description' 'xpra-start' '--scope' '--user' 'python3' '/usr/bin/xpra' 'start' '--start=/usr/bin/firefox' '--systemd-run=no'
Job for run-rfff30b9e85394e8198e446d53091aa64.scope failed.
See "systemctl status run-rfff30b9e85394e8198e446d53091aa64.scope" and "journalctl -xe" for details.
  1. journalctl -xe
    -- Unit xpra.socket has finished starting up.
    -- 
    -- The start-up result is RESULT.
    Feb 10 13:56:36 MintyCraptop sudo[7753]: pam_unix(sudo:session): session closed for user root
    Feb 10 13:57:18 MintyCraptop dbus-daemon[646]: Unknown group "power" in message bus configuration file
    Feb 10 13:57:18 MintyCraptop dbus-daemon[646]: Unknown username "whoopsie" in message bus configuration file
    Feb 10 13:57:18 MintyCraptop dbus-daemon[646]: [system] Reloaded configuration
    Feb 10 13:57:19 MintyCraptop sudo[7497]: pam_unix(sudo:session): session closed for user root
    Feb 10 13:57:45 MintyCraptop polkitd(authority=local)[675]: Registered Authentication Agent for unix-process:8190:9116487 (system bus name :1.1871 [/usr/bin/pkttyagent --notify-fd 5 --fallback
    Feb 10 13:57:45 MintyCraptop systemd[1442]: run-rfff30b9e85394e8198e446d53091aa64.scope: Failed to add PIDs to scope's control group: Permission denied
    Feb 10 13:57:45 MintyCraptop systemd[1442]: run-rfff30b9e85394e8198e446d53091aa64.scope: Failed with result 'resources'.
    Feb 10 13:57:45 MintyCraptop systemd[1442]: Failed to start xpra-start.
    -- Subject: Unit UNIT has failed
    -- Defined-By: systemd
    -- Support: http://www.ubuntu.com/support
    -- 
    -- Unit UNIT has failed.
    

So how do I resolve it? First I make sure that firefox or whatever the initial program is, isn't running (though it would be nice if this didn't have to happen).

ps aux | grep firefox
technic+  8327  0.0  0.0  14428  1012 pts/1    S+   14:10   0:00 grep --color=auto firefox

If that doesn't prove to yield anything as shown above, I then borrow the following information I found in a previous systemd ticket on GitHub and apply the "fix", though this is most certainly not from my understanding a very good solution and should only be done to personal machine and not within production environments...

#!/bin/bash

set -euo pipefail

file=/sys/fs/cgroup/user.slice/user-$(id -u).slice/cgroup.procs

sudo chown $(whoami):root $file
sudo chmod g+w            $file

Thanks, let me know if there's a missing dependency or something you want me to test though I really feel like this is an XPRA bug as many of the systems I've tried this on were fresh installations and still encountered this bug.

Change History (4)

comment:1 Changed 7 days ago by Antoine Martin

Description: modified (diff)
Milestone: 3.14.0
Owner: changed from Antoine Martin to Tmanok

Job for run-rfff30b9e85394e8198e446d53091aa64.scope failed.

Just tried it on Ubuntu Bionic and the problem did not occur.
Maybe you're running on Linux Mint instead?

The cause of the error:

Failed to add PIDs to scope's control group: Permission denied

See #2042, #1536, #1105.

First I make sure that firefox or whatever the initial program is, isn't running (though it would be nice if this didn't have to happen).

This is a "feature" of Firefox and most browsers. They have no intention of fixing it and there's absolutely nothing we can do in xpra.

I found in a previous systemd ticket ...

Same as ticket:2042?#comment:6.

I have merged a workaround (r25206) based on this solution: facebook/flow : disable cgroups under broken versions of systemd.

Backport to v3 in r25207.
Until this fix lands in a stable release, you can:

  • use the beta channel (new builds will land shortly)
  • apply the patch by hand
  • disable systemd-run: --systemd-run=no (or edit /etc/xpra/conf.d/60_server.conf)
  • start your sessions from an ssh login (already disables systemd-run)

comment:2 Changed 7 days ago by Tmanok

Status: newassigned

Hello Antoine,

I will attempt again on Linux Mint 19.3 and Ubuntu 18.10 (also Ubuntu 20.04 in May. (normally when they actually release a stable version....))

The workaround you've offered [--systemd-run=no] is actually something I've tried in the past, I will happily retry as my memory is not serving me well enough today to remember whether it worked for me. Additionally I appreciate your GitHub source fix from the FB GitHub Bot, my my Facebook has been helpful in software development lately (found anecdotally for my personal and work problems as of late).

This is a "feature" of Firefox and most browsers.

Oh darn, I appreciate the information. I'll be sure to not run Firefox normally on the account used before an XPRA server start command is issued then.

Thank you for your time and support on this matter, once again you and the XPRA team make a great project. The only reason why I wanted to submit this ticket was because this was the fifth or sixth machine that I had tried to install and run the server off of and it failed the first try on all of them.

One last question actually, do you know when the default apt repositories will have a newer version of XPRA? [bionic stable, buster main, other supported repositories etc etc]. The current version seems to be somewhere in the ~2.4 to ~2.6 ballpark depending on the distribution.
Thanks again!

Tmanok [Triston]

Last edited 7 days ago by Antoine Martin (previous) (diff)

comment:3 Changed 7 days ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

I will attempt again on Linux Mint 19.3 and Ubuntu 18.10 (also Ubuntu 20.04 in May.

18.10 is EOL. You probably mean 19.10.

do you know when the default apt repositories will have a newer version of XPRA?

Those are never updated and always carry dangerously buggy versions.
See wiki/Packaging/DistributionPackages.

comment:4 Changed 7 days ago by Tmanok

18.10 is EOL. You probably mean 19.10.

Ah too true,

I meant 18.04, https://ubuntu.com/about/release-cycle I don't normally use non LTS editions.

https://xpra.org/trac/wiki/Packaging/DistributionPackages

Now that's a heck of a good demonstration about Distro Maintenance getting out of hand! I should do polling to graph some of my favourite applications! Also, this is part of the reason why my days of Homebrew on MacOS have endured with me on linux, packages like YouTubeDL can be compiled straight from GitHub? using HomeBrew? with version tracking, dependency resolution etc.

Thanks,

Tmanok [Triston]

Last edited 7 days ago by Tmanok (previous) (diff)
Note: See TracTickets for help on using tickets.