[Sts-sponsors] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. - The actual regression potential is a user asking for a reboot and not getting it. - Other than that the changes in the code are very small and simple and unlikely to break anything. + The actual regression potential is a user asking for a reboot and not getting it, so the largest regression potential is any existing users (human or programmatic) that are requesting a scheduled shutdown but not checking the return value for error. + Any other regression would likely result in the system incorrectly not rebooted, or incorrectly scheduled for reboot. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it, so the largest regression potential is any existing users (human or programmatic) that are requesting a scheduled shutdown but not checking the return value
[Sts-sponsors] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
minor comment, for systemd (and really all packages) I like to name the
patches with the lp bug number, so i changed your patch name to add the
lp1911187- prefix.
also another minor comment, as we'd discussed before I made a slight
change to the comment in the patch for clarification:
if (arg_when > 0)
return logind_schedule_shutdown();
-/* no delay, or logind is not at all available */
+/* no delay */
if (geteuid() != 0) {
if (arg_dry_run || arg_force > 0) {
(void) must_be_root();
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1911187
Title:
scheduled reboot reboots immediately if dbus or logind is not
available
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Focal:
In Progress
Status in systemd source package in Groovy:
In Progress
Bug description:
[IMPACT]
When, for whatever reason, logind or dbus is not available scheduled reboot
reboots the machine immediately.
From the sources it seems that this is intended :
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318
However, I report this as a bug since this is against the logic of a
scheduled reboot; if someone schedules a reboot they want the system to reboot
at the specified time not immediately.
There has been a discussion upstream (
https://github.com/systemd/systemd/issues/17575 ) and
a PR ( https://github.com/systemd/systemd/pull/18010 ).
Upstream community is not willing to accept the patch but debian is.
I open this bug to to pull the patch into Ubuntu once it lands in debian.
[TEST PLAN]
The simpler reproducer is to disable dbus to imitate the real world
case.
# systemctl stop dbus.service
# systemctl stop dbus.socket
# shutdown +1140 -r "REBOOT!"
Failed to set wall message, ignoring: Failed to activate service
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Failed to call ScheduleShutdown in logind, proceeding with immediate
shutdown: Connection timed out
Connection to groovy closed by remote host.
Connection to groovy closed.
[WHERE PROBLEM COULD OCCUR]
This patch changes the behaviour of scheduled reboot in case logind or dbus
has failed.
Originally, if logind is not available (call to logind bus fails
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319)
it proceeds with immediate shutdown.
This patch changes this behaviour and instead of shutting down it does
nothing.
The actual regression potential is a user asking for a reboot and not getting
it.
Other than that the changes in the code are very small and simple and
unlikely to break anything.
[OTHER]
This is now fixed in H, currently affects B,G,F.
Debian bug reports :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042
Upstream issue : https://github.com/systemd/systemd/issues/17575
PR : https://github.com/systemd/systemd/pull/18010
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+subscriptions
--
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
@joalif, one thing I noticed, that isn't important for this SRU, is that
the !ENABLE_LOGIND case still has a log message indicating shutdown will
happen immediately, i.e.:
int logind_schedule_shutdown(void) {
#if ENABLE_LOGIND
...stuff...
#else
return log_error_errno(SYNTHETIC_ERRNO(ENOSYS),
"Cannot schedule shutdown without logind
support, proceeding with immediate shutdown.");
#endif
}
however, since the caller has been changed to return error instead of
immediate reboot, maybe that message should be changed as well. I'd
actually suggest that both messages in this function, that state what
will happen next but rely on the caller to actually do what the log
states, are in the wrong place, and the *calling* function should log an
appropriate message about what it's doing next instead of this function.
Doesn't matter for this though since we do define ENABLE_LOGIND for our
builds, just a suggestion if you want to send a patch to debian :)
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1911187
Title:
scheduled reboot reboots immediately if dbus or logind is not
available
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Focal:
In Progress
Status in systemd source package in Groovy:
In Progress
Bug description:
[IMPACT]
When, for whatever reason, logind or dbus is not available scheduled reboot
reboots the machine immediately.
From the sources it seems that this is intended :
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318
However, I report this as a bug since this is against the logic of a
scheduled reboot; if someone schedules a reboot they want the system to reboot
at the specified time not immediately.
There has been a discussion upstream (
https://github.com/systemd/systemd/issues/17575 ) and
a PR ( https://github.com/systemd/systemd/pull/18010 ).
Upstream community is not willing to accept the patch but debian is.
I open this bug to to pull the patch into Ubuntu once it lands in debian.
[TEST PLAN]
The simpler reproducer is to disable dbus to imitate the real world
case.
# systemctl stop dbus.service
# systemctl stop dbus.socket
# shutdown +1140 -r "REBOOT!"
Failed to set wall message, ignoring: Failed to activate service
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Failed to call ScheduleShutdown in logind, proceeding with immediate
shutdown: Connection timed out
Connection to groovy closed by remote host.
Connection to groovy closed.
[WHERE PROBLEM COULD OCCUR]
This patch changes the behaviour of scheduled reboot in case logind or dbus
has failed.
Originally, if logind is not available (call to logind bus fails
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319)
it proceeds with immediate shutdown.
This patch changes this behaviour and instead of shutting down it does
nothing.
The actual regression potential is a user asking for a reboot and not getting
it.
Other than that the changes in the code are very small and simple and
unlikely to break
[Sts-sponsors] [Bug 1916635] [NEW] [plugin][ovn-central] timeout on non-leader host
Public bug reported: [IMPACT] When running the ovn_central plugin on a non-leader host the sbctl command hangs indefinitely until the sosreport timeout kicks in. [TEST CASE] * Run 'sos report -a' (AKA sosreport -a) which should exercise ovn-central, if the detection criteria are met. In this case if package 'ovn-central' is installed. AND/OR * Run 'sos report -o ovn_central' (AKA sosreport -o ovn_central) which will enable the ovn_central plugin only. * The plugin will then timeout and logs will be as follows: Setting up plugins ... [plugin:ovn_central] Could not open DB schema file /usr/share/openvswitch/ovn-nb.ovsschema: [Errno 2] No such file or directory: '/usr/share/openvswitch/ovn-nb.ovsschema' [plugin:ovn_central] Could not open DB schema file /usr/share/openvswitch/ovn-sb.ovsschema: [Errno 2] No such file or directory: '/usr/share/openvswitch/ovn-sb.ovsschema' [plugin:ovn_central] added cmd output 'ovn-nbctl show' [plugin:ovn_central] added cmd output 'ovn-sbctl show' [plugin:ovn_central] added cmd output 'ovn-sbctl lflow-list' [plugin:ovn_central] added cmd output 'ovn-nbctl get-ssl' [plugin:ovn_central] added cmd output 'ovn-nbctl get-connection' [plugin:ovn_central] added cmd output 'ovn-sbctl get-ssl' [plugin:ovn_central] added cmd output 'ovn-sbctl get-connection' [plugin:ovn_central] added cmd output 'ovn-nbctl list Load_Balancer' [plugin:ovn_central] added cmd output 'ovn-nbctl list ACL' [plugin:ovn_central] added cmd output 'ovn-nbctl list Logical_Switch_Port' [plugin:ovn_central] added cmd output 'journalctl --no-pager --unit ovn-northd' Running plugins. Please wait ... Starting 1/1 ovn_central [Running: ovn_central] [plugin:ovn_central] collecting path '/var/log/ovn/ovn-controller.log' [plugin:ovn_central] collecting output of 'ovn-nbctl show' [plugin:ovn_central] collecting output of 'ovn-sbctl show' [WHERE PROBLEM COULD OCCUR] If something arise after this change. It will only affect the data collection of the ovn-central plugin individually. It won't affect other plugins nor core functionalities. Worse case scenario would be that user will have to collect ovn debugging data manually (outside a usual sosreport run) in order to provide it to a third-party support vendor. [OTHER INFORMATION] Upstream issue: https://github.com/sosreport/sos/issues/2418 Upstream PR: https://github.com/sosreport/sos/pull/2419 ** Affects: sosreport (Ubuntu) Importance: Undecided Assignee: Eric Desrochers (slashd) Status: In Progress ** Affects: sosreport (Ubuntu Focal) Importance: Undecided Assignee: Edward Hope-Morley (hopem) Status: In Progress ** Affects: sosreport (Ubuntu Groovy) Importance: Undecided Assignee: Edward Hope-Morley (hopem) Status: In Progress ** Affects: sosreport (Ubuntu Hirsute) Importance: Undecided Assignee: Eric Desrochers (slashd) Status: In Progress ** Tags: seg sts sts-sponsor-slashd ** Also affects: sosreport (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Groovy) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Hirsute) Status: New => In Progress ** Changed in: sosreport (Ubuntu Hirsute) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Groovy) Assignee: (unassigned) => Edward Hope-Morley (hopem) ** Changed in: sosreport (Ubuntu Focal) Assignee: (unassigned) => Edward Hope-Morley (hopem) ** Changed in: sosreport (Ubuntu Groovy) Status: New => In Progress ** Changed in: sosreport (Ubuntu Focal) Status: New => In Progress ** Description changed: [IMPACT] When running the ovn_central plugin on a non-leader host the sbctl command hangs indefinitely until the sosreport timeout kicks in. [TEST CASE] * Run 'sos report -a' (AKA sosreport -a) which should exercise ovn-central, if the detection criteria are met. In this case if package 'ovn-central' is installed. * Run 'sos report -o ovn_central' (AKA sosreport -o ovn_central - * The plugin will timeout an logs will be as follows: + * The plugin will then timeout and logs will be as follows: Setting up plugins ... [plugin:ovn_central] Could not open DB schema file /usr/share/openvswitch/ovn-nb.ovsschema: [Errno 2] No such file or directory: '/usr/share/openvswitch/ovn-nb.ovsschema' [plugin:ovn_central] Could not open DB schema file /usr/share/openvswitch/ovn-sb.ovsschema: [Errno 2] No such file or directory: '/usr/share/openvswitch/ovn-sb.ovsschema' [plugin:ovn_central] added cmd output 'ovn-nbctl show' [plugin:ovn_central] added cmd output 'ovn-sbctl show' [plugin:ovn_central] added cmd output 'ovn-sbctl lflow-list' [plugin:ovn_central] added cmd output 'ovn-nbctl get-ssl' [plugin:ovn_central] added cmd output 'ovn-nbctl get-connection' [plugin:ovn
[Sts-sponsors] [Bug 1915072] Re: [plugin][ovn-central][ovn-host] include logs
I have reported a separate bug for it for tracking purposes: https://bugs.launchpad.net/bugs/1916635 - Eric -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1915072 Title: [plugin][ovn-central][ovn-host] include logs Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: Fix Committed Status in sosreport source package in Groovy: Fix Committed Status in sosreport source package in Hirsute: Fix Released Bug description: [Impact] The existing ovn plugins are a bit limited e.g. they don't collect any logs. I'd like to extend them a little to include logs and a bit more debug info i.e. these plugins: sos/report/plugins/ovn_central.py sos/report/plugins/ovn_host.py [Test Case] * Connect to host with ovn. * Run sosreport (this can be run in various ways but for the sake of this documenation let's use the most common): ** sosreport -a (If the right ovn condition are met (e.g. right pkgs installed, ...) the plugin will detect it and run the plugin accordingly. ** sosreport -o ovn_central ** sosreport -o ovn_host [Where problems could occur] If something arise after this change. It will only affect the data collection of the ovn-host and/or ovn-central plugin individually. It won't affect other plugins nor core functionalities. Worse case scenario would be that user will have to collect ovn debugging data manually (outside a usual sosreport run) in order to provide it to a third-party support vendor. [Other information] Issues: https://github.com/sosreport/sos/issues/2409 PR: https://github.com/sosreport/sos/pull/2410 Commit: https://github.com/sosreport/sos/commit/e1845a1f2bc1ba1f556e3dde60ae9a2584d3f825 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1915072/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1916635] [NEW] [plugin][ovn-central] timeout on non-leader host
You have been subscribed to a public bug by Eric Desrochers (slashd): [IMPACT] When running the ovn_central plugin on a non-leader host the sbctl command hangs indefinitely until the sosreport timeout kicks in. [TEST CASE] * Run 'sos report -a' (AKA sosreport -a) which should exercise ovn-central, if the detection criteria are met. In this case if package 'ovn-central' is installed. AND/OR * Run 'sos report -o ovn_central' (AKA sosreport -o ovn_central) which will enable the ovn_central plugin only. * The plugin will then timeout and logs will be as follows: Setting up plugins ... [plugin:ovn_central] Could not open DB schema file /usr/share/openvswitch/ovn-nb.ovsschema: [Errno 2] No such file or directory: '/usr/share/openvswitch/ovn-nb.ovsschema' [plugin:ovn_central] Could not open DB schema file /usr/share/openvswitch/ovn-sb.ovsschema: [Errno 2] No such file or directory: '/usr/share/openvswitch/ovn-sb.ovsschema' [plugin:ovn_central] added cmd output 'ovn-nbctl show' [plugin:ovn_central] added cmd output 'ovn-sbctl show' [plugin:ovn_central] added cmd output 'ovn-sbctl lflow-list' [plugin:ovn_central] added cmd output 'ovn-nbctl get-ssl' [plugin:ovn_central] added cmd output 'ovn-nbctl get-connection' [plugin:ovn_central] added cmd output 'ovn-sbctl get-ssl' [plugin:ovn_central] added cmd output 'ovn-sbctl get-connection' [plugin:ovn_central] added cmd output 'ovn-nbctl list Load_Balancer' [plugin:ovn_central] added cmd output 'ovn-nbctl list ACL' [plugin:ovn_central] added cmd output 'ovn-nbctl list Logical_Switch_Port' [plugin:ovn_central] added cmd output 'journalctl --no-pager --unit ovn-northd' Running plugins. Please wait ... Starting 1/1 ovn_central [Running: ovn_central] [plugin:ovn_central] collecting path '/var/log/ovn/ovn-controller.log' [plugin:ovn_central] collecting output of 'ovn-nbctl show' [plugin:ovn_central] collecting output of 'ovn-sbctl show' [WHERE PROBLEM COULD OCCUR] If something arise after this change. It will only affect the data collection of the ovn-central plugin individually. It won't affect other plugins nor core functionalities. Worse case scenario would be that user will have to collect ovn debugging data manually (outside a usual sosreport run) in order to provide it to a third-party support vendor. [OTHER INFORMATION] Upstream issue: https://github.com/sosreport/sos/issues/2418 Upstream PR: https://github.com/sosreport/sos/pull/2419 ** Affects: sosreport (Ubuntu) Importance: Undecided Assignee: Eric Desrochers (slashd) Status: In Progress ** Affects: sosreport (Ubuntu Focal) Importance: Undecided Assignee: Edward Hope-Morley (hopem) Status: In Progress ** Affects: sosreport (Ubuntu Groovy) Importance: Undecided Assignee: Edward Hope-Morley (hopem) Status: In Progress ** Affects: sosreport (Ubuntu Hirsute) Importance: Undecided Assignee: Eric Desrochers (slashd) Status: In Progress ** Tags: seg sts -- [plugin][ovn-central] timeout on non-leader host https://bugs.launchpad.net/bugs/1916635 You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1915072] Re: [plugin][ovn-central][ovn-host] include logs
Patch submitted - https://github.com/sosreport/sos/pull/2419 -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1915072 Title: [plugin][ovn-central][ovn-host] include logs Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: Fix Committed Status in sosreport source package in Groovy: Fix Committed Status in sosreport source package in Hirsute: Fix Released Bug description: [Impact] The existing ovn plugins are a bit limited e.g. they don't collect any logs. I'd like to extend them a little to include logs and a bit more debug info i.e. these plugins: sos/report/plugins/ovn_central.py sos/report/plugins/ovn_host.py [Test Case] * Connect to host with ovn. * Run sosreport (this can be run in various ways but for the sake of this documenation let's use the most common): ** sosreport -a (If the right ovn condition are met (e.g. right pkgs installed, ...) the plugin will detect it and run the plugin accordingly. ** sosreport -o ovn_central ** sosreport -o ovn_host [Where problems could occur] If something arise after this change. It will only affect the data collection of the ovn-host and/or ovn-central plugin individually. It won't affect other plugins nor core functionalities. Worse case scenario would be that user will have to collect ovn debugging data manually (outside a usual sosreport run) in order to provide it to a third-party support vendor. [Other information] Issues: https://github.com/sosreport/sos/issues/2409 PR: https://github.com/sosreport/sos/pull/2410 Commit: https://github.com/sosreport/sos/commit/e1845a1f2bc1ba1f556e3dde60ae9a2584d3f825 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1915072/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1915072] Re: [plugin][ovn-central][ovn-host] include logs
Yeah, let me know once you have an upstream fix approved/merged, and I'll go ahead and update the ovn plugin. - Eric -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1915072 Title: [plugin][ovn-central][ovn-host] include logs Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: Fix Committed Status in sosreport source package in Groovy: Fix Committed Status in sosreport source package in Hirsute: Fix Released Bug description: [Impact] The existing ovn plugins are a bit limited e.g. they don't collect any logs. I'd like to extend them a little to include logs and a bit more debug info i.e. these plugins: sos/report/plugins/ovn_central.py sos/report/plugins/ovn_host.py [Test Case] * Connect to host with ovn. * Run sosreport (this can be run in various ways but for the sake of this documenation let's use the most common): ** sosreport -a (If the right ovn condition are met (e.g. right pkgs installed, ...) the plugin will detect it and run the plugin accordingly. ** sosreport -o ovn_central ** sosreport -o ovn_host [Where problems could occur] If something arise after this change. It will only affect the data collection of the ovn-host and/or ovn-central plugin individually. It won't affect other plugins nor core functionalities. Worse case scenario would be that user will have to collect ovn debugging data manually (outside a usual sosreport run) in order to provide it to a third-party support vendor. [Other information] Issues: https://github.com/sosreport/sos/issues/2409 PR: https://github.com/sosreport/sos/pull/2410 Commit: https://github.com/sosreport/sos/commit/e1845a1f2bc1ba1f556e3dde60ae9a2584d3f825 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1915072/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1915072] Re: [plugin][ovn-central][ovn-host] include logs
I've created https://github.com/sosreport/sos/issues/2418 to address this problem. Perhaps we should wait for that to be fixed and then bundle it with this SRU. ** Bug watch added: github.com/sosreport/sos/issues #2418 https://github.com/sosreport/sos/issues/2418 -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1915072 Title: [plugin][ovn-central][ovn-host] include logs Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: Fix Committed Status in sosreport source package in Groovy: Fix Committed Status in sosreport source package in Hirsute: Fix Released Bug description: [Impact] The existing ovn plugins are a bit limited e.g. they don't collect any logs. I'd like to extend them a little to include logs and a bit more debug info i.e. these plugins: sos/report/plugins/ovn_central.py sos/report/plugins/ovn_host.py [Test Case] * Connect to host with ovn. * Run sosreport (this can be run in various ways but for the sake of this documenation let's use the most common): ** sosreport -a (If the right ovn condition are met (e.g. right pkgs installed, ...) the plugin will detect it and run the plugin accordingly. ** sosreport -o ovn_central ** sosreport -o ovn_host [Where problems could occur] If something arise after this change. It will only affect the data collection of the ovn-host and/or ovn-central plugin individually. It won't affect other plugins nor core functionalities. Worse case scenario would be that user will have to collect ovn debugging data manually (outside a usual sosreport run) in order to provide it to a third-party support vendor. [Other information] Issues: https://github.com/sosreport/sos/issues/2409 PR: https://github.com/sosreport/sos/pull/2410 Commit: https://github.com/sosreport/sos/commit/e1845a1f2bc1ba1f556e3dde60ae9a2584d3f825 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1915072/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. - [TEST CASE] + [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. - [REGRESSION POTENTIAL] + [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. - [SCOPE] + [OTHER] - This is already in H, need backporting to B,G,F. - - Ubuntu-hirsute commits : - - https://git.launchpad.net/~ubuntu-core- - dev/ubuntu/+source/systemd/commit/?h=ubuntu- - hirsute&id=ce31df6711a8e112cff929ed3bbdcd194f876270 - - https://git.launchpad.net/~ubuntu-core- - dev/ubuntu/+source/systemd/commit/?h=ubuntu- - hirsute&id=ec1130fece7ca66273773119775e51045a74122c - - Debian commits : - - https://salsa.debian.org/systemd- - team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270 - - https://salsa.debian.org/systemd- - team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c - - [OTHER] + This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour a
[Sts-sponsors] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Tags removed: sts-sponsors-ddstreet ** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. + [SCOPE] + + This is already in H, need backporting to B,G,F. + + Ubuntu-hirsute commits : + + https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/? + h=ubuntu-hirsute&id=ce31df6711a8e112cff929ed3bbdcd194f876270 + + https://git.launchpad.net/~ubuntu-core- + dev/ubuntu/+source/systemd/commit/?h=ubuntu- + hirsute&id=ec1130fece7ca66273773119775e51045a74122c + + Debian commits : + + https://salsa.debian.org/systemd- + team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270 + + https://salsa.debian.org/systemd- + team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c + [OTHER] - - This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 ** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [SCOPE] This is already in H, need backporting to B,G,F. Ubuntu-hirsute commits : - https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/? - h=ubuntu-hirsute&id=ce31df6711a8e112cff929ed3bbdcd194f8
[Sts-sponsors] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Changed in: systemd (Ubuntu Focal) Assignee: Dan Streetman (ddstreet) => Ioanna Alifieraki (joalif) ** Changed in: systemd (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [SCOPE] This is already in H, need backporting to B,G,F. Ubuntu-hirsute commits : https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/systemd/commit/?h=ubuntu- hirsute&id=ce31df6711a8e112cff929ed3bbdcd194f876270 https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/systemd/commit/?h=ubuntu- hirsute&id=ec1130fece7ca66273773119775e51045a74122c Debian commits : https://salsa.debian.org/systemd- team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270 https://salsa.debian.org/systemd- team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c [OTHER] Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Changed in: systemd (Ubuntu Groovy) Assignee: (unassigned) => Ioanna Alifieraki (joalif) -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [SCOPE] This is already in H, need backporting to B,G,F. Ubuntu-hirsute commits : https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/systemd/commit/?h=ubuntu- hirsute&id=ce31df6711a8e112cff929ed3bbdcd194f876270 https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/systemd/commit/?h=ubuntu- hirsute&id=ec1130fece7ca66273773119775e51045a74122c Debian commits : https://salsa.debian.org/systemd- team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270 https://salsa.debian.org/systemd- team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c [OTHER] Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Changed in: systemd (Ubuntu Focal) Assignee: Ioanna Alifieraki (joalif) => Dan Streetman (ddstreet) -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [SCOPE] This is already in H, need backporting to B,G,F. Ubuntu-hirsute commits : https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/systemd/commit/?h=ubuntu- hirsute&id=ce31df6711a8e112cff929ed3bbdcd194f876270 https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/systemd/commit/?h=ubuntu- hirsute&id=ec1130fece7ca66273773119775e51045a74122c Debian commits : https://salsa.debian.org/systemd- team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270 https://salsa.debian.org/systemd- team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c [OTHER] Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Tags added: sts-sponsors-ddstreet ** Changed in: systemd (Ubuntu Focal) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Groovy) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Bionic) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Ioanna Alifieraki (joalif) -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1911187] [NEW] scheduled reboot reboots immediately if dbus or logind is not available
You have been subscribed to a public bug by Ioanna Alifieraki (joalif): [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. >From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 ** Affects: systemd (Ubuntu) Importance: Medium Assignee: Ioanna Alifieraki (joalif) Status: Confirmed ** Affects: systemd (Ubuntu Bionic) Importance: Medium Status: Confirmed ** Affects: systemd (Ubuntu Focal) Importance: Medium Status: Confirmed ** Affects: systemd (Ubuntu Groovy) Importance: Medium Status: Confirmed ** Tags: sts sts-sponsors -- scheduled reboot reboots immediately if dbus or logind is not available https://bugs.launchpad.net/bugs/1911187 You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1915072] Re: [plugin][ovn-central][ovn-host] include logs
Tested with focal-updates 4.0-1~ubuntu0.20.04.3 and it has the same issue -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1915072 Title: [plugin][ovn-central][ovn-host] include logs Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: Fix Committed Status in sosreport source package in Groovy: Fix Committed Status in sosreport source package in Hirsute: Fix Released Bug description: [Impact] The existing ovn plugins are a bit limited e.g. they don't collect any logs. I'd like to extend them a little to include logs and a bit more debug info i.e. these plugins: sos/report/plugins/ovn_central.py sos/report/plugins/ovn_host.py [Test Case] * Connect to host with ovn. * Run sosreport (this can be run in various ways but for the sake of this documenation let's use the most common): ** sosreport -a (If the right ovn condition are met (e.g. right pkgs installed, ...) the plugin will detect it and run the plugin accordingly. ** sosreport -o ovn_central ** sosreport -o ovn_host [Where problems could occur] If something arise after this change. It will only affect the data collection of the ovn-host and/or ovn-central plugin individually. It won't affect other plugins nor core functionalities. Worse case scenario would be that user will have to collect ovn debugging data manually (outside a usual sosreport run) in order to provide it to a third-party support vendor. [Other information] Issues: https://github.com/sosreport/sos/issues/2409 PR: https://github.com/sosreport/sos/pull/2410 Commit: https://github.com/sosreport/sos/commit/e1845a1f2bc1ba1f556e3dde60ae9a2584d3f825 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1915072/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1915072] Re: [plugin][ovn-central][ovn-host] include logs
I've tested this on focal and there is an issue but it might not be related to this patchset: I tested running sosreport with -a on both an ovn-controller and an ovn- central host. This all works fine until I run it on an ovn-central host that is not the db leader (you can only run commands on a leader host). In this case the ovn_central plugin hangs - https://pastebin.ubuntu.com/p/MJg3VHmS3y/. These commands were added in previous commit cc63749 so are already in sosreport. Ill open a bug on sosreport to see if there is a way to work around this. -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1915072 Title: [plugin][ovn-central][ovn-host] include logs Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: Fix Committed Status in sosreport source package in Groovy: Fix Committed Status in sosreport source package in Hirsute: Fix Released Bug description: [Impact] The existing ovn plugins are a bit limited e.g. they don't collect any logs. I'd like to extend them a little to include logs and a bit more debug info i.e. these plugins: sos/report/plugins/ovn_central.py sos/report/plugins/ovn_host.py [Test Case] * Connect to host with ovn. * Run sosreport (this can be run in various ways but for the sake of this documenation let's use the most common): ** sosreport -a (If the right ovn condition are met (e.g. right pkgs installed, ...) the plugin will detect it and run the plugin accordingly. ** sosreport -o ovn_central ** sosreport -o ovn_host [Where problems could occur] If something arise after this change. It will only affect the data collection of the ovn-host and/or ovn-central plugin individually. It won't affect other plugins nor core functionalities. Worse case scenario would be that user will have to collect ovn debugging data manually (outside a usual sosreport run) in order to provide it to a third-party support vendor. [Other information] Issues: https://github.com/sosreport/sos/issues/2409 PR: https://github.com/sosreport/sos/pull/2410 Commit: https://github.com/sosreport/sos/commit/e1845a1f2bc1ba1f556e3dde60ae9a2584d3f825 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1915072/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
