core/service: store BUSERROR= & VARLINKERROR= received and show them through systemctl status #33430
Conversation
github-actions
bot
added
documentation
sd-bus
systemctl
please-review
YHNdnzj
force-pushed
the
buserror-notify
branch
2 times, most recently
from
785484c
to
eea6866
Compare
|
love it. thanks! |
poettering
added
good-to-merge/waiting-for-ci 👍
|
I guess you can add "Fixes: #6073" somewhere |
varlinkctl has this nice feature that it sends the varlink error it gets via sd_notify() to the caller. With systemd#33430 ths information is collected and exposed in "systemctl status". Let's make sure we can provide the same in busctl: also propagate errors the same way. With this and systemd#33430 we can comprehensively close systemd#6073
yuwata
added
good-to-merge/with-minor-suggestions
and removed
good-to-merge/waiting-for-ci 👍
varlinkctl has this nice feature that it sends the varlink error it gets via sd_notify() to the caller. With systemd#33430 ths information is collected and exposed in "systemctl status". Let's make sure we can provide the same in busctl: also propagate errors the same way. With this and systemd#33430 we can comprehensively close systemd#6073
|
for writing a test case, consider just cherry-picking #33434 into this PR (and closing that PR then), and then fire off a |
varlinkctl has this nice feature that it sends the varlink error it gets via sd_notify() to the caller. With previous commits this information is collected and exposed in "systemctl status". Let's make sure we can provide the same in busctl: also propagate errors the same way. With this we can comprehensively close systemd#6073
YHNdnzj
added
good-to-merge/waiting-for-ci 👍
YHNdnzj
force-pushed
the
buserror-notify
branch
2 times, most recently
from
cba33f6
to
9ab9bff
Compare
| @@ -2745,6 +2745,8 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice { | |||
| readonly s FileDescriptorStorePreserve = '...'; | |||
There was a problem hiding this comment.
btw, downstreams asked us to always make changes to TODO in separate commits because they often backport patches and the TODO stuff is a major source of conflicts because it changes so often, but not what they care about for backports.
There was a problem hiding this comment.
Hmm, TODO is mostly about new features, so I don't quite understand why they would backport those commits in the first place... I prefer not to split such changes out if this is only about backporting.
There was a problem hiding this comment.
well, people backport stuff for many reasons. i personally would be a lot more conservative, but then again i am not a package maintainer.
|
lgtm. |
github-actions
bot
removed
the
good-to-merge/waiting-for-ci 👍
Fixes: #6073