Cockpit: service not running: enable versus start

[garrett]

Currently, in Containers and Machines, if the service is not running, we show an empty state pattern that allows someone to start the service.

However, this impacts the user experience, as it doesn't actually solve the problem. Someone will have to start the service each and every time they sign into the machine with Cockpit.

Right now, this means someone has to know to navigate over to a page like /system/services#/libvirtd.service, click on "enable" and jump back to the previous page.

It should be possible to enable & start the service directly from the empty state page.

[garrett]

This issue comes from PR #8493 (machines: detect if libvirt is running + add errors bar).

[garrett]

There are a couple of options that I immediately see:

Option 1

$SERVICE is Not Running
[Start Service] [Enable & Start Service]

---

Option 2

$SERVICE is Not Running
☑ Always start $SERVICENAME
[Start Service]

---

I'm leaning to option 2. What do you think, @andreasn, @suomiy?

[garrett]

Minor edits, riffing on option 2, with libvirt as an example:

Virtualization Service (libvirt) is Not Active
☑ Automatically start libvirt on boot
[Start libvirt]

_note: libvirt is always lowercase, so it's a little awkward in places like this_

[andreasn]

Yeah, I think that could work.
I think it's to prefer over the [Enable & Start Service] button, since if a service is enabled, but was stopped for some reason while the machine was on, it would imply to enable it, even though it's already enabled.
So it should probably be unchecked by if it's currently disabled, and checked if it's currently enabled (I think?!?)

[suomiy]

the checkbox option seems fine.

I think the link to the service still should be there; to be able to check the status and logs of the service.

In my opinion only the link could be enough, because the service page already manages that. I know the user has to click once to get there and enable it, but this happens only once.

[mareklibra]

What if the service is enabled (supposed to be running) but is stopped due to a failure? To investigate that, the user would enjoy the link to see logs, etc.

The empty state pattern shall provide solution for a "common" reason, so I like the Start button here, same as the check-box for enabling it.
Implementation can reuse pkg/lib/service.js, so via D-Bus.

[andreasn]

I agree the link is useful, because the administrator is then able to see why this service isn't running by checking the logs of the service.

[garrett]

@suomiy: Yeah, but instead of actually fixing things, we're jumping in the middle of someone's flow:

1. telling them to go somewhere else (with a link at least)
2. do something else when they're there (click a button to enable, but first they have to understand what's going on on that page, so it takes a few seconds)
3. then hoping they find their way back* to try to do what they were going to do in the first place.

• (the back arrow button _should_ work, but a lot of people are afraid to try that in web apps, as it often messes things up in many others)

So I think it should be solvable from the "empty state" screen.

---

I also agree that some sort of link to services makes sense. The question is how to represent it in the page. These are three ideas on how to combine enabling as well as troubleshooting:

Option 2.A (Troubleshoot)

We could have a secondary troubleshooting button in option 2 that takes someone to the service page. (Things like this are currently done elsewhere in Cockpit, but often with a dialog that pops up.)

Virtualization Service (libvirt) is Not Active
☑ Automatically start libvirt on boot
[Troubleshoot] [[Start libvirt]]

Option 1.A (Link)

It could exist as a link in the sub-text, but I think we'd have to use option 1 for the buttons instead if so.

Virtualization Service (libvirt) is Not Active
View the libvirt service page
[Start Service] [[Enable & Start Service]]

Option 2.B (Retry)

We could default to option 2, but if it fails a second time, then it shows a link to the service page.

Virtualization Service (libvirt) is Not Active
☑ Automatically start libvirt on boot
[[Start libvirt]]

Becomes:

There is a Problem Starting Virtualization Services
[[Visit the libvirt service page]]

[suomiy]

I think the option 2.A looks ok, but I am still not sure if we shouldn't mention the service somehow instead of troubleshoot or just to put the link from 1.A there

[suomiy]

We could default to option 2, but if it fails a second time

I would not use this because we would have to store the state in the ui. And the options would change if you refresh the page.

[suomiy]

current state:

this was left the same

is it fine like this?

[garrett]

Yeah, I like that. :+1:

In cases where the friendly name and service name are basically the same, we shouldn't have to include the service name. At least for Virtualization Service / libvirt and Container Service / docker, we'd need the additional name for clarification. For something like Firewall / firewalld, it wouldn't make sense (just drop the firewalld reference).

I'm assuming Troubleshoot goes to the service page. Is that correct?

@andreasn: What do you think?

[suomiy]

I'm assuming Troubleshoot goes to the service page. Is that correct?

yes

[andreasn]

@garrett looks good to me. My only reservation is that it's called "Virtualization Daemon" in the systemd unit file, so that's what it's called on the Service page. But that's mostly nitpicking from my side. Good to go, I would say!

[garrett]

Drifting _slightly_ offtopic:

We should try to avoid saying "Daemon" wherever possible. It's an old UNIX joke reference from long ago (1963, Project MAC) that's a bit offputting for anyone not in-the-know.

There's a bunch of other computer terminology that should be replaced too, like master/slave (primary/secondary, primary/replica), motherboard (mainboard), daughtercard (expansion card), etc. Thankfully, for basically every one of these, there's a drop-in replacement available. Same goes for daemon, as they basically all provide one or another type of "service".

Some of the above outdated terms have the possibility of showing up in Cockpit if we're not careful about it. Again, it's great there are drop-in replacements. (…And the replacements are usually even better descriptions than the original terms too!)

Anyway, 2¢. :wink:

[andreasn]

That is a separate bug that needs to be filed in the appropriate place. We have no control over the names in the unit files that show up in Cockpit.

[garrett]

Yep, totally. We do have the responsibility to get these issues addressed, as we need to be conscious of strings that show up in Cockpit. (Someone using Cockpit won't know that the string originally came from _X, Y, Z_ tools and subsystems.)

[suomiy]

oki, I will start writing tests for this

[garrett]

(Sidechannel)

@andreasn: On my own desktop (not server, where there might be even more, and definitely different service files), a quick grep tally shows that 47 different services use "daemon" (case insensitive) in their descriptions. And checking that against the RPM database shows that these service files come from 47 different packages. Yikes.

IMO, a valid compromise here would be to _basically_ replace "daemon" with "service" in highly visible strings (such as within this UI). If someone is browsing the services page, we can still show what the service files state, as it's kind of a crusty under-the-hood view of the system — nearly every OS has places like this somewhere.

At least daemon isn't quite as problematic as some of the other terminology mentioned.

[andreasn]

Ugh. Forget I said anything about daemon.

[garrett]

(Sorry)

[martinpitt]

The empty state pattern on the Virtual Machines page has worked like in https://github.com/cockpit-project/cockpit/issues/8661#issuecomment-369210180 for a while, so I think this is fixed.