[systemd-devel] systemd-analyze-197 broken

[Kok, Auke-jan H]

On Mon, Jan 14, 2013 at 4:23 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Tue, Jan 15, 2013 at 01:16:24AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
>> On Mon, Jan 14, 2013 at 03:55:42PM -0800, Kok, Auke-jan H wrote:
>> > On Mon, Jan 14, 2013 at 3:38 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>> > > Am 15.01.2013 00:00, schrieb Jan Engelhardt:
>> > >> On Monday 2013-01-14 23:44, Reindl Harald wrote:
>> > >>
>> > >>> what does systemd-analyze try to tell me?
>> > >>> systemd-197 itself works fine
>> > >>>
>> > >>> [root at testserver:~]$ systemd-analyze
>> > >>> Traceback (most recent call last):
>> > >>>  File "/usr/bin/systemd-analyze", line 23, in <module>
>> > >>>    from gi.repository import Gio
>> > >>> ImportError: No module named gi.repository
>> > >>
>> > >> python is telling you about a missing (python) module named
>> > >> gi.repository
>> > >
>> > > but
>> > >
>> > > * where does it comre from (gi.repository doe snot tell me anything)
>> >
>> > this is up to your distribution to provide, unfortunately.
>> >
>> > > * when was it introduced
>> > > * why does the package it not pull as dependencie with hopefully
>> > >   not again circle-deps to a lot of other packages
>> > >
>> > > does systemd really need to introduce one 3rd party component
>> > > after the next (libmicrohttpd as example) which will sooner
>> > > or later terrible break due incompatible changes in this minefiled
>> >
>> > I don't think it's as bad as you portray it, but I have an intern
>> > software engineer that I will be making systemd-analyze (the non-plot
>> > parts - the plot parts should be replaced by bootchart IMO) rewrite in
>> > C, so hopefully we can put some of this behind us soon enough.
>> I think that fixing a trivial packaging error (one line of missing
>> Depends:) with a rewrite from scratch is the wrong way to go.
>> The available man-hours would be much better spent improving
>> systemd-analyze to provide better diagnostics, nicer output, more
>> features, etc. Rewriting it in C serves little purpose: neither it is
>> a performance critical program, nor does it run in initrd. Nor
>> is it going to be easier to develop. To the contrary, as long as it is
>> written in Python, it is trivial to dynamically load the graphical
>> libraries only when necessary.  With C code this is possible too, but
>> requires _much_ more code.
> Regarding features: for example systemd-analyze only shows sucessfully
> started programs.  It doesn't say anything useful about .device units
> which timed out. It would be incredibly useful to tell the user that
> her systemd took 300s to boot up because everything was waiting for a
> missing swap partition.

That's something valuable indeed - also something I'd love to put an intern on.

I don't have anything against Python per se - but for our intern
program I cannot justify having an intern program in Python if the
goal is that the interns long term get prepared for e.g. Linux kernel
programming.

Second, I've encountered now on 3 distributions already that
systemd-analyze is a useless tool when you bring up platforms and look
at early boot performance just to the fact that you generally don't
have any python stack around at that time. By the time you do have
python running on the platform, the boot time performance should
already be known and optimized. You can't wait with boot time
performance work until the Python stack has been finalized, it is just
not that important.

Cheers,

Auke