[systemd-devel] [PATCH] cgtop: useful error messages when bootup fails

[shawn]

On Tue, 2012-05-22 at 13:12 +0200, Lennart Poettering wrote: 
> On Mon, 21.05.12 23:04, shawn (shawnlandden at gmail.com) wrote:
> 
> Heya,
> 
> > Uggh, sorry for sending that super-buggy patch. Here is a better
> > version.
> > 
> > On Mon, 2012-05-21 at 22:59 -0700, Shawn Landden wrote: 
> > > cgtop quits on startup if all the cgroup mounts it expects are not ready.
> > > Provide user with some indication of why cgtop failed.
> 
> > >From 33fa72fdbed3e82d9910e8ecf4b04502fe266ebf Mon Sep 17 00:00:00 2001
> > From: Shawn Landden <shawnlandden at gmail.com>
> > Date: Mon, 21 May 2012 22:54:41 -0700
> > Subject: [PATCH] cgtop: useful error messages when bootup fails
> > 
> > cgtop quits on startup if all the cgroup mounts it expects are not ready.
> > Provide user with some indication of why cgtop failed.
> 
> Hmm, this is misleading. THis has little to do with being ready, as the
> cgroup VFS are mounted synchronously very early in PID 1 and it is
> basically very hard to run in parallel with that.
> 
> So this check actually would check for something different: whether the
> system was booted with systemd at all, and whether the respective cgroup
> controller has been enabled in the kernel at all. But for the former an
> excplicit early check for sd_booted() would probably a nicer choice
> (though I must say I shiver at the idea that we add this to all our
> tools). And for the latter we should probably fix things so that the
> tool works fine even if cpuacct, memory and blkio (or any subset of them
> are not available), after all those controllers should be optional.
100% agree. 
> 
> How did you start cgtop so that you ran into this problem?
On an armel system running systemd, but which doesn' have the memory (or
blkid) cgroups sections, I presume because I didn't compile them in.
(I'd rather not have the overhead of the memory one)

I had to use strace to get any idea why it didn't work.

I ran across a similar issue with nspawn before. Alot of these tools
require specific kernel features, and why they fail correctly they don't
really give useful error messages. 
> 
> Lennart
> 


-- 
-Shawn Landden