Shutdown needs often longer than usual

Bug #1729192 reported by Removed by request
8
Affects Status Importance Assigned to Milestone
irqbalance (Ubuntu)
Fix Released
Undecided
Unassigned
systemd (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I'm using Ubuntu 18.04 dev with irqbalance 1.1.0-2.3ubuntu1 and for some weeks on shutting down the system often (around 50%-75%) I'm seeing that the irqbalance job needs some seconds to shutdown causing to delay the system shutdown noticeable.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
I doubt it is irqbalance shutdown in your case.
That shutdown is just sending a kill signal and that is it, there is not much more it does.
I quickly checked but for me it didn't look the same.

Two things to get more details:
1. does on the system running also take quite some time if you do like "systemctl stop irqbalance"?
2. I'd assume that systemd concurrently stops multiple things and irqbalance is just the last to print but not the one you are actually waiting on. To check that unfortunately [1] isn't implemented - but you can check if [2] gives you some hints what it is actually waiting on.

[1]: https://github.com/systemd/systemd/issues/3371
[2]: https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Changed in irqbalance (Ubuntu):
status: New → Incomplete
Revision history for this message
Removed by request (removed3425744) wrote :

> 1. does on the system running also take quite some time if you do like "systemctl stop irqbalance"?

I have tested this now multiple times by stopping and starting it again and all looked fine.

> 2. I'd assume that systemd concurrently stops multiple things and irqbalance is just the last to print but not the one you are actually waiting on.

Based on the above this might be true. So is it a known issue that systemd prints wrong things? I think this is an issue that should be actually fixed before tinkering around on every shutdow delay issue (also [1] blames that [2] isn't reliable enough so it would eventually also make sense to wait for [1]'s implementation).

Changed in irqbalance (Ubuntu):
status: Incomplete → New
Revision history for this message
Removed by request (removed3425744) wrote :

I have extended the test a bit by instead of testing if a manual irqbalance shutdown is fast or slow I have tested if the system shutdown is also delayed if irqbalance is manually shutdown before a system shutdown. I have made a few system shutdowns with and without irqbalance running and in the cases where irqbalance was running the most times the system shutdown was delayed with systemd blaming the irqbalance job on the console while without irqbalance running the system shutdown was always fast.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hmm,
that seems odd - but it doesn't have enough to recreate and debug.
As irqbalance isn't strictly required you could consider uninstalling or masking it in systemd.
But that is only a workaround.

For the sake of going forward I merged the latest irqbalance which should show up soon in 18.04.
Could you try if you can reproduce so in e.g. a KVM guest.

If so you could redirect the console and maybe even pipe it through something adding timestamps.
Sorry I'm not the biggest expert on systemd debugging - maybe there are much better options out there I don't know for shutdown delay analysis.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Setting incomplete missing further info, also there were no similar bug reports since then.

Changed in irqbalance (Ubuntu):
status: New → Incomplete
Changed in systemd (Ubuntu):
status: New → Incomplete
Revision history for this message
Removed by request (removed3425744) wrote :

After I updated irqbalance to the next major version (shortly after your last message from 2017) the issue didn't appear anymore since then.

Changed in irqbalance (Ubuntu):
status: Incomplete → Fix Released
Changed in systemd (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.