[systemd-devel] List all available units

Lennart Poettering lennart at poettering.net
Wed Aug 8 09:31:05 PDT 2012


On Tue, 07.08.12 16:35, Václav Pavlín (vpavlin at redhat.com) wrote:

> Hi everyone,
> 
> I started to work on these two bugs (if I solve the first one, the
> second one will be almost solved as well):
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=748512
> https://bugzilla.redhat.com/show_bug.cgi?id=790768
> 
> My idea is to get list of loaded units, then list of unit files and then
> get info for units, which are in file list, but not in list of loaded
> units. Then I can print info for all units available in the system
> (whether they are loaded or not).

I am not sure we should include the units from "list-unit-files" in the
output of "list-units", as this would increase the output quite a bit,
and would be hardly helpful in many cases, and slow.

There are differences between the concepts of loaded unit and unit file
on disk. Some units do not exist as unit files, some unit files don't
exist as units. Some files exist in many instances, and so on. 

Yes, it probably make sense to have a way to generate a list of all
units and all unit files, and merge it in some way, but I am not sure
that should be exposed as "list-units" nor as "list-unit-files". Also,
this option is necessarily slow, since (like list-unit-files) goes to
disk and parses a lot of files, hence this is nothing we should confront
the user with on first sight, but only on explicit request.

So, dunno, I am not entirely sure how to expose this best. We probably
should get the interface right, and agree how this would be exposed to
the user, before we actually think about implementing it. Neither of the
three options I currently see (extend "systemctl list-units", extend
"systemctl list-unit-files", add a new systemctl verb) are that
pretty in my eyes.

If we present the user with a list like this we probably should show a
tree view of some kind since the unit file getty at .service might get
instantiated a couple of times as "getty at tty1.service" and so on, and
hence is in a tree-like relationship. 

Michal, Kay, do you have any suggestions how we should expose this?

Another option would be to add a notice about "systemctl
list-unit-files" in the footer of "systemctl list-units". That should
already be a big imprvoement, since most people probably interrpet the
current advice of using "--all" like this.

Another option would be to add "systemctl complete" as hidden option for
usage only by bash completion, that does the merging.

> I would extract code responsible for loading unit_infos from
> systemctl.c/list_units to the function (so it will be reusable) and do
> the same with the systemctl.c/lis_unit_files.
> 
> I would like to use hashmap to store loaded units, because it will be
> faster, than using array, to check it against unit file list. With this
> it would be nice to use hashmap directly in functions list_units and
> output_units_list, so I don't have to move data from array to hashmap
> and back to array.

Yes, storing this in a hashmap does make sense. But really, before we
get hacking we should think about the UI of this.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list