'call to get_tasks_recursive failed' errors from su

Bug #1534090 reported by Tim Edwards
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
cgmanager (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

In Ubuntu 14.04 all of a sudden I'm seeing these two error messages coming up every time I use su -, whether in a script or interactive shell:
call to remove-on-empty (freezer:0) failed: invalid request
call to get_tasks_recursive failed: Invalid arguments received in reply

Example and how to reproduce:

root@localhost:~# su - test "echo hello"
call to remove-on-empty (freezer:0) failed: invalid request
-su: echo hello: No such file or directory
call to get_tasks_recursive failed: Invalid arguments received in reply
call to get_tasks_recursive failed: Invalid arguments received in reply
root@localhost:~# su - test
call to remove-on-empty (freezer:0) failed: invalid request
test@localhost:~$

This only seems to affect Ubuntu 14.04

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in shadow (Ubuntu):
status: New → Confirmed
Revision history for this message
Michał Sawicz (saviq) wrote :

I'm actually getting the same on xenial.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I see the same on 14.04, even without "-" on the su.
The test also lacked the -c for the command, and "-" would need to be at the end or specified as "-l".
Also we might execute something that doesn't add output, to easen debugging (/bin/true)

Anyway - that just refines the simple test, the issue is there as reported.

Simplified test:
su testuser -c "/bin/true"

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

The only reference I found to get_tasks_recursive seems far away in cgmanager (http://changelogs.ubuntu.com/changelogs/pool/main/c/cgmanager/cgmanager_0.32-4ubuntu1.1/changelog and https://linuxcontainers.org/it/cgmanager/manpages/man1/cgm.1.html)

Yet I found that my Xenial Test system didn't show the issue, while Michael before mentioned it did for him.
I realized that this Xenial System had no cgmanager installed.

So I installed full lxd (which is what usually brings cgmanager to your system) and e voila I was able to reproduce the issue on Xenial as well now.

The output is slightly different (more and repeated on Xenial)
Trusty
call to get_tasks_recursive failed: Invalid arguments received in reply

Xenial
call to remove-on-empty (freezer:0) failed: invalid request
call to get_tasks_recursive failed: Invalid arguments received in reply
call to get_tasks_recursive failed: Invalid arguments received in reply

I removed lxd and all its dependencies again and only installed cgmanager on the Xenial system. This pulls in libcgmanager0 and libnih-dbus1 as well, but nothing else.
With those installed the issue does not yet appear, so it seems to need more of these packages to actually trigger.
I tried to separate the lxd dependencies and found that libpam-cgm, likely to hook from pam (which is what su uses) into cgmanager.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

cgmanager is a service you can reach via dbus for cgroup management.
It is used in this case via libpam-cgm to "Create cgroups for user login sessions"

I stopped the service and reran it in verbose mode
sudo /sbin/cgmanager -m name=systemd -v

Then in another console I tried to trigger the issue again with
su testuser -c "/bin/true"

On the triggering task I still get:
su -m testuser -c "/bin/true"
call to remove-on-empty (freezer:1) failed: invalid request
call to get_tasks_recursive failed: Invalid arguments received in reply

On the verbose log I get:
Connection from private client
ListControllers: Client fd is: 6 (pid=21503, uid=0, gid=1000)
MovePid: Client fd is: 6 (pid=21503, uid=0, gid=1000)
21503 moved to freezer:/ by 21503's request
Create: Client fd is: 6 (pid=21503, uid=0, gid=1000)
Created /run/cgmanager/fs/freezer/user/paelzer for 21503 (0:1000)
cgmanager_create: returning 0; existed is 1
MovePid: Client fd is: 6 (pid=21503, uid=0, gid=1000)
21503 moved to freezer:user/paelzer by 21503's request
Create: Client fd is: 6 (pid=21503, uid=0, gid=1000)
Created /run/cgmanager/fs/freezer/user/paelzer/0 for 21503 (0:1000)
cgmanager_create: returning 0; existed is 1
Create: Client fd is: 6 (pid=21503, uid=0, gid=1000)
Created /run/cgmanager/fs/freezer/user/paelzer/1 for 21503 (0:1000)
cgmanager_create: returning 0; existed is -1
Chown: Client fd is: 6 (pid=21503, uid=0, gid=1000)
RemoveOnEmpty: Client fd is: 6 (pid=21503, uid=0, gid=1000)
cgmanager: remove-on-empty request for pre-mounted controller
MovePid: Client fd is: 6 (pid=21503, uid=0, gid=1000)
21503 moved to freezer:1 by 21503's request
Disconnected from private client
Connection from private client
ListControllers: Client fd is: 6 (pid=21503, uid=0, gid=1000)
MovePid: Client fd is: 6 (pid=21503, uid=0, gid=1000)
21503 moved to freezer:/ by 21503's request
ListChildren: Client fd is: 6 (pid=21503, uid=0, gid=1000)
GetTasksRecursive: Client fd is: 6 (pid=21503, uid=0, gid=1000)
GetTasksRecursive: Client fd is: 6 (pid=21503, uid=0, gid=1000)
Remove: Client fd is: 6 (pid=21503, uid=0, gid=1000)
Removed /run/cgmanager/fs/freezer/user/paelzer/1 for 21503 (0:1000)
GetTasksRecursive: Client fd is: 6 (pid=21503, uid=0, gid=1000)
Disconnected from private client

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I can use cgm to do some getrecursive calls without issue, like this:
cgm gettasksrecursive freezer

With that I think my quick debugging has reached its end, but lets assign to the proper components now that we know.

affects: shadow (Ubuntu) → cgmanager (Ubuntu)
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

@tkedwards,

Could you please show your cgmanager version?

dpkg -l | grep cgmanager

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Confirmed it happens for me with the lxd-git-master ppa.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

I'll remove all those error messages printed to stderr in pam/cgmanager.c. If cgmanager
were going to last I would take the time to pass the errors back up to log them to syslog,
but it's just not worth it.

Changed in cgmanager (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cgmanager - 0.39-2ubuntu5

---------------
cgmanager (0.39-2ubuntu5) xenial; urgency=medium

  * Update previous patch to remove all the (non-initial) errors printed to
    stderr. (LP: #1534090)

 -- Serge Hallyn <email address hidden> Mon, 18 Jan 2016 10:50:00 -0800

Changed in cgmanager (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Tim Edwards (tkedwards) wrote :

Thanks! Would it also be possible to fix in trusty and wily?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1534090] Re: 'call to get_tasks_recursive failed' errors from su

Trusty doesn't have libpam-cgm. Do you mean in ppas?

Revision history for this message
Tim Edwards (tkedwards) wrote :

Yeah, sorry meant in the ppa. I use it on both trusty and wily: deb http://ppa.launchpad.net/ubuntu-l
xc/lxd-stable/ubuntu wily main

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Yup that'll get the update.

Revision history for this message
Tim Edwards (tkedwards) wrote :

Thanks!

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cgmanager (Ubuntu Wily):
status: New → Confirmed
no longer affects: cgmanager (Ubuntu Wily)
Revision history for this message
Michele Giacomoli (michele-giacomoli) wrote :

Actually libpam-cgm is in trusty-backports now. Can we have the fix backported for this package too?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Ye,s we should SRU to that, thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.