Updated: September 17, 2018
This sounds like a rather obscure title, don't you think? Well, picture this. You have an Ubuntu distro flavor installed, in my case Kubuntu 18.04 Beaver or KDE neon, and you want to reboot. For some odd reason, clicking the right button through the system menu does not do anything. There's no restart happening. OK, so you go for a command line trick.
You open a console window and you type sudo reboot. Only you receive the following error message: Failed to start reboot.target: Transaction is destructive. See system logs and 'systemctl status reboot.target' for details. What. At this point, it seems like a hard boot is the only option. But then, that's not really a solution. Let's investigate.
Problem in more detail
I noticed this issue on several occasions in various Ubuntu distributions on my multi-boot Lenovo G50 system. Granted, it's a living, breathing test box, and it's always got distros getting removed and installed and partitions formatted and whatnot. At first, I could not correlate the issue to anything special.
neon@tester:~$ sudo reboot
Failed to start reboot.target: Transaction is destructive.
See system logs and 'systemctl status reboot.target' for details.
I decided to consult the logs. Indeed, this is the first thing you ought to do, because you should follow the clues, if there are any, and work slowly and methodically, without introducing permanent changes unless you know what you're doing. Unfortunately, there wasn't much value in the systemd log - this is another instance that shows the limited usefulness of the systemd framework. The complexity just makes for very tricky debugging.
reboot.target - Reboot
Loaded: loaded (/lib/systemd/system/reboot.target; disabled; vendor preset
Active: inactive (dead)
However ... I was able to correlate this phenomenon with another problem related to the boot process that I've encountered recently - that of the upgraded Kubuntu booting much more slowly - and the same issue seems to have affected neon, too. We've discussed the slow boot problem in great detail, and we did learn that this was caused by a nonexistent swap device being written in the /etc/fstab file. For some reason, during the upgrade process, the Ubuntu installer changed the /dev/sdXY notation to UUID=, but it used an identifier that does not exist, or existed only briefly during the installation. With two separate cases occurring, this led me to believe this is not an isolated case, but some sort of a bug introduced recently.
The direct impact of the swap device issue was very slow boot - but there seems to be another side effect, and that would be the reboot problem. Indeed, neon had the same slowness and the system logs showed a similar issue to what we did with Kubuntu.
Jul 18 15:42:30 tester systemd:
device/start timed out.
Jul 18 15:42:30 tester systemd: Timed out waiting for device dev-disk-by\x2duuid-388a79ac\x2d27b7\x2d42f5\x2dac13\x2d0de1263748ae.device.
Jul 18 15:42:30 tester systemd: Dependency failed for /dev/disk/by-uuid/388a79ac-27b7-42f5-ac13-0de1263748ae.
Jul 18 15:42:30 tester systemd: dev-disk-by\x2duuid-388a79ac\x2d27b7\x2d42f5\x2dac13\x2d0de1263748ae.swap: Job dev-disk-by\x2duuid-388a79ac\x2d27b7\x2d42f5\x2dac13\x2d0de1263748ae.
swap/start failed with result 'dependency'.
Jul 18 15:42:30 tester systemd: dev-disk-by\x2duuid-388a79ac\x2d27b7\x2d42f5\x2dac13\x2d0de1263748ae.device: Job dev-disk-by\x2duuid-388a79ac\x2d27b7\x2d42f5\x2dac13\x2d0de1263748ae.
device/start failed with result 'timeout'.
At this point, I decided to fix the swap issue - without doing anything else. I changed the /etc/fstab file to use the good ole /dev/sda10 (the comment in the file even says ... /dev/sdXY was swap before installation), and then activated the swap partition (swapon -a). I tried to reboot again, and voila, it worked this time. No more systemd errors!
So, for whatever odd reason - the presence of a bogus swap device in the /etc/fstab file slowed down the boot, which is understandable, but it also prevented the distro(s) from rebooting, which does not seem plausible. The only thing that comes to mind is that the system shutdown scripts are trying to unmount a filesystem that does not exist and failing, and so they feel there's a filesystem that would need to be force-unmounted and lead to possible data loss. That is ONLY a guess, mind, and the intent might be noble, but the execution is poor.
I don't like "magical" articles - I hate the unpredictability that they convey. Then again, I often surprise myself in that my technical intuition gets me to the right place and correct answers pretty much every single time. It's decades of work and experience compressed into singular moments, and you can't really reason them out fully.
On this topic, if you encounter an issue like the above - a Linux box that cannot be rebooted, please check whether you have stale, unresponsive or bogus mounts in your system. In fact, you might even discover a few other odd problems and side affects you might not have thought about, like the slow boot issue. I am happy that I had the chance to work around these, as it gives me a little more understanding into the chaos that is the Linux boot sequence post init. The important thing is, despite the somewhat gimpy availability of useful data in systemd logs, you can still work toward reasonable solutions. And that would be all. Happy Linuxing.