From: Christoph Heiss <c.heiss@proxmox.com>
To: Wolfgang Bumiller <w.bumiller@proxmox.com>
Cc: pbs-devel@lists.proxmox.com
Subject: Re: [pbs-devel] [PATCH proxmox-backup] api2/node/services: Handle optional services and expose unit-state
Date: Thu, 15 Dec 2022 11:30:11 +0100 [thread overview]
Message-ID: <62764cb6-920e-3fb3-53d8-4ede38e5e037@proxmox.com> (raw)
In-Reply-To: <20221215092927.nvgsoptxcngd4w2k@casey.proxmox.com>
On 12/15/22 10:29, Wolfgang Bumiller wrote:
> On Wed, Dec 14, 2022 at 10:42:59AM +0100, Christoph Heiss wrote:
>> .. in the same way the PVE api does, esp. regarding the logic to handle
>> oneshot and missing services.
>>
>> This then allows re-using the GUI parts from there as well, so that the
>> services page in PVE and PBS looks the same.
>>
>> Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
>> ---
>> src/api2/node/services.rs | 21 ++++++++++++++++++++-
>> 1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/api2/node/services.rs b/src/api2/node/services.rs
>> index 0cc1857e..534c41e8 100644
>> --- a/src/api2/node/services.rs
>> +++ b/src/api2/node/services.rs
>> @@ -76,12 +76,27 @@ fn get_full_service_state(service: &str) -> Result<Value, Error> {
>> fn json_service_state(service: &str, status: Value) -> Value {
>> if let Some(desc) = status["Description"].as_str() {
>> let name = status["Name"].as_str().unwrap_or(service);
>> - let state = status["SubState"].as_str().unwrap_or("unknown");
>> +
>> + let state = if status["Type"] == "oneshot" && status["SubState"] == "dead" {
>> + &status["Result"]
>
> Reading the perl equivalent, if we end up here but `Result` does not
> exist we'd see 'dead' in perl as it falls back to SubState (which at
> this point is known to be 'dead'), while we'd show 'unknown' in this
> case from the 'unwrap_or' below.
> Not sure if this can happen though?
Not sure either, but if it is a finished one-shot service, systemd
*should* always provide a result. That's IMHO a very reasonable
assumption and was my thought while working on it too.
Playing a bit with `systemctl show` and looking at some services, it
really seems that the Result property is always present, even for e.g.
non-existing services.
But if you want, I can send a v2 and add the fallback to SubState here
as well, to align it with the Perl equivalent.
>> [..]
>> --
>> 2.30.2
next prev parent reply other threads:[~2022-12-15 10:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 9:42 [pbs-devel] [PATCH proxmox-backup/widget-toolkit] Handle optional services and expose more details Christoph Heiss
2022-12-14 9:42 ` [pbs-devel] [PATCH proxmox-backup] api2/node/services: Handle optional services and expose unit-state Christoph Heiss
2022-12-15 9:29 ` Wolfgang Bumiller
2022-12-15 10:30 ` Christoph Heiss [this message]
2022-12-14 9:43 ` [pbs-devel] [PATCH widget-toolkit] node/ServiceView: Show unit-state column in PBS too Christoph Heiss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=62764cb6-920e-3fb3-53d8-4ede38e5e037@proxmox.com \
--to=c.heiss@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=w.bumiller@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox