[systemd-devel] [PATCH] [RFCv4] Add Listen* to dbus properties

[Zbigniew Jędrzejewski-Szmek]

On Fri, Apr 05, 2013 at 07:16:59PM +0200, Lennart Poettering wrote:
> On Wed, 03.04.13 23:12, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> 
> > > So, consider adding some form of numbering to the list of listen
> > > addresses. Perhaps something like:
> > > 
> > > >> >            0: ListenStream: /tmp/stream1
> > > >> >            1: ListenDatagram: /tmp/stream2
> > Hi,
> > I forgot to reply to this, and just remembered looking at Lennart's TODO prunning.
> > 
> > Numbering from 0 (or 1) would be misleading, because the sockets
> > get passed as 3, 4, etc. But numbering from 3 would be misleading
> > too, because when more than one .socket is used, the fd's from the
> > second .socket and subsequent ones are shifted. I don't think that
> > there's a way to sanely number those sockets without complicating
> > things significantly. Also, it wouldn't fit the current layout scheme :)
> > OTOH, just counting them by hand should be easy enough. I think
> > that having more than one or two is quite rare.
> 
> I fully agree with Zbyszek. The order matters enough to show them with
> the original order, but OTOH is too much of an implementation detail
> that should irrelevant to the admin to emphasize it in the output by
> prefixing them with numbering.
> 
> BTW, semi-related to this: I wonder if we should add a new set of
> commands to systemctl that lists sockets, timers path units in an
> "alternative" output mode, i.e. where they aren't ordered by unit names,
> but rather by the resource name the units cover.
> 
> For example, for "systemctl list-sockets" it could do:
> 
> LISTEN              UNIT          ACIVATES
> 127.0.0.1:4711      foobar.socket foobar.service
> /run/systed/journal waldo.socket  waldo.socket
I pushed something like that. It's a bit bare-bones right now.
A surprising amount of code was requried (>300 lines), but adding
smarts should be easy now. I think it would be nice to e.g. show
socket-units listening on external addresses or those activating
services under root in red or something. 

Zbyszek

> And for "systemctl list-timers" or so it could give a
> break-down of all active timer events with the time the expire next as
> first column. Something
> like this:
> 
> NEXT                LEFT            UNIT         ACTIVATES
> 2013-06-12 12:34:11 4 months 5 days foobar.timer foobar.service
> 2013-05-01 07:31:51 2 months 3 days waldo.timer  waldo.service
> 
> (The latter was proposed by viking-ice on the hackfest iirc, all i am
> suggesting is to do the same for sockets and other trigger units)