Sidenote: had to mangle my links, cause this is my first post on this forum and can’t include links yet. 
I too have experienced this for many months now and yesterday got annoyed enough to investigate some more.
Same output as yours showed up in journalctl --since="10 minutes ago"
when run right after a reboot that experienced that 90 second timeout during the shutdown phase.
I did some research yesterday and found a temporary workaround (explained at end).
Some background info
A related discussion in the arch forum ( bbs[.]archlinux[.]org /viewtopic.php?id=291829) proposed a workaround using systemd
and DBUS, which didn’t work for me (just failed starting jackdbus
during startup each time).
An issue on github ( /jackaudio/jack2/issues/971 ) was also created quite some time ago. Still open.
The problem
When one has installed jackdbus
(or usually jack
), then during startup phase a “DBUS systemd service” (/usr/share/dbus-1/services/org.jackaudio.service
) starts jackdbus auto
and puts it in a kind of “suspended state”.
Once one then also starts jackd
(e.g. via cadence
), then jackdbus
becomes “active”.
At least it seems that way, because whenever I skip starting jackd
via cadence
after booting my system, then the subsequent shutdown would not trigger the timeout at all.
But if jackdbus
became active, then yeah, the timeout issue during shutdown phase happens each time.
The issue now is that somehow jackdbus
process is not reacting to SIGTERM, which might be issued by systemd during shutdown. Subsequently the timeout keeps going until it is elapsed.
BTW: This is also what that proposed workaround re arch forum was about: making jackdbus
(or rather the systemd service around it) issue a SIGKILL upon the service being stopped.
A potential workaround for now
The basic idea is simply to kill the jackdbus
process before performing a shutdown like so: pkill -9 jackdbus
As a result the timeout won’t happen.
But of course, having to remember to run this each time before a reboot / shutdown to avoid the timeout is annoying and easily forgotten.
I’m using Xfce
, so I automated it via Settings -> Session and Startup
, running a simple bash script with pkill -9 jackdbus
command in it, using triggers “on shutdown” and `“on restart” (I set up two entries basically).
I would assume there’s something similar for KDE, Gnome, etc., but likely not for simpler WMs (i3, etc.)
Now whenever I’m using “reboot” or “shutdown” via the power menu, I’m no longer experiencing the timeout!
BTW: An alternative workaround attempt which didn’t work
I also tried to somehow get it working with a systemd service:
cat /etc/systemd/system/jackdbus_cleanup.service
[Unit]
Description=Kill 'jackdbus' process before shutdown to avoid timeout scenario.
Before=shutdown.target
[Service]
Type=oneshot
ExecStart=pkill -9 jackdbus
[Install]
WantedBy=shutdown.target
systemctl daemon-reload
systemctl enable jackdbus_cleanup.service
But this didn’t help (still got the timeout).
From what I saw, the timeout happens immediately after logging out and lightdm
(display manager) having stopped.
The above service just tries to run before the “shutdown” target runs.
But seemingly that’s already too late.
I couldn’t find how one specifically targets this desired moment in time right after leaving the “graphical” target while approaching the “shutdown” target.
Why would this be better?
For one, because it’s DE agnostic, so would work even for “i3”, etc.
And two, because (not verified yet, but I assume so), the above approach with “Xfce - Session and Startup” likely would not trigger if one were to run sudo reboot
or sudo shutdown now
, which could be a pitfall at times.