@Dooremone I know that Apple already patched it in Sierra and High Sierra, I’m not sure about Windows.
I must warn however that Mac, Linux and Windows patches only protect the operating system stack. Wi-Fi Devices will still be vulnerable until their drivers (or firmware, depending on the hardware device) are updated. So do not use public hotspots for a while, even if you are patched.
Keep an eye also on your router at home. Your ISP (if it is a rental), or the manufacturer, should be issuing an update soon. If they don’t it is time to get angry.
And until then disable any standby features on your router, if they exist. Do not allow the router to enter standby mode until it is patched, because it will try to offload data to to your system and that data handshake will be vulnerable to this type of attack. (The router can be powered off, of course. It’s only standby mode that is vulnerable)
Sadly, not everyone can afford the continuous use of cellular data, and using an Ethernet cable is just not viable since it takes away the mobility we have all grown accustomed to.
It’s however interesting that this is just another example of the message that has been repeatedly sent for a little over a decade that new technologies cannot just be built on top of 40 year old protocols and expect to “just work”. Never before in our 60 year old history of inter-connectivity have we been so exposed. It’s dramatic and it is also having an impact on much more than our individual lives. It’s affecting entire governments and international politics and relationships. And the terrible danger that represents in a world where one half hates the other half.
So, the advise is REALLY to stop caring so much for one’s mobility, aka convenience. We must really start lowering our expectations of what we want the internet to do for us and not be so damn sold to it. It’s a simple fact, illustrated by the ever increasing number of incidents (and increasing gravity of each), that the internet technology is simply not prepared for the many of the things we are trying to do with it.
I need to learn to live with the idea that I really don’t need to be connected to the internet when I’m commuting between home and the work. That if I am taking a vacation, I don’t need to make a post on the facebook every time I go to the loo. And certainly I should train myself to become more a spectator and less of an actor on the internet.
I’m a technologist, make no mistake! A modernist in many respects, and a man of science down to the very marrow of my DNA. I am not advocating going back to the past, nor stopping the development of internet technology. But on the other hand, never before have I witnessed technology being so misused and so childishly applied and, what’s worse, not for the sake of a genuine human need, but as a means to fabricate new needs. Mobility and Convenience, being vague and meaningless words that are nonetheless taking a mantle of importance in our lives that no one in their right mind can justify.
So yes! Cable internet, cellular phones, more email and less cloud, more desktops and less tablets, this and more (much more) is not an iHermit way of living. It’s instead becoming a necessity and a more prudent way of exposing ourselves and our families to the technological windstorm of the internet. And a clear message to the technologists that we want better, not worse technology. That’s the true definition of technological development.
As @joekamprad says, this does throw back to an old systemd buggy behavior that comes and goes and that apparently no one can really get an hold of.
This has been discussed on systemd bug tracker with some detail on a few occasions. From what I observed a few months back (I think 6 months ago or so) the general non-canonical sentiment was that this is mainly caused by misbehaving applications that don’t respond correctly to systemd and the kernel signals during shutdown. The part of the bug that belongs to systemd is its incapacity to detect these situations and act immediately – at the very least to allow hardware watchdogs to catch these situations, since currently not even an hardware watchdog will stop the 90 second timeout.
But the current state of this bug(?) and the more than likely fact that this will remain a problem with systemd for a very long time, shouldn’t discourage you. There’s some things you should know:
Your logs indicate a clean shutdown regardless of the non stopped job. No errors, and the effective shutdown of the journald service, which is the last thing to go before systemd surrenders itself to the kernel. So this indicates that it is perfectly safe for you to press your power button at this time. But given this, I would also remove
quietfrom your grub settings. So you can better gauge when you entered the timeout state and to judge if it is indeed fine to hit the power button on a per shutdown basis.
Notice that the 90 second waiting period is symptomatic of the default
DefaultTimeout[Start|Stop]Secsettings in your /etc/systemd/system.conf. You don’t have any other timeouts set in your machine with this period. And these are the default timeouts for units, which is why you can be sure this is a program misbehaving to terminating signals. This means that new versions of the program may fix this (chromium, conky, firefox, mariadb, … all at one point or another caused these delays on systemd machines).
A probably boring exercise is to make sure you stop as many services and as many processes as possible before you shutdown the system and see how it behaves. Do this enough times and you may end up detect the culprit.
I’m not sure why you are getting two
Exec=entries. That is an error in the desktop file, unless there is more than one [section] in the file. Are you sure you didn’t omit the
^symbol in the command above and one of those entries is instead
From here I advise three courses of action:
1st Assuming the .desktop file is indeed fine and there is only one
Exec=entry, the plot thickens and there should be no reason for this to fail. Is Nautilus installed on your system and does it work when you invoke it through other means?
2nd Locate the System Settings in Gnome (I don’t use it so I don’t know where this is in the GUI). There must be something about Default Applications. Within you may make changes to the default File Manager.
3rd With the above failing, show me the contents of the file, please:
$ cat /usr/share/applications/org.gnome.Nautilus.desktop
It seems that you don’t have a default application associated with the
inode/directorymimetype. Which is unusual, since I think Antergos has it set for you, based on the DE you chose during installation. To be sure issue the following command:
$ xdg-mime query default inode/directory
If you get no output, there’s no association and you need to create one. If you get an output, then that is the
.desktopfile that is being associated with directories.
Assuming you got output, if you then type the following command, you should learn what program is being used to open directories, and possibly why it is failing:
$ grep '^Exec=' ~/.local/share/applications/<name.desktop>
Replace <name.desktop> with the file named by the previous command.
Otherwise, you need to create the association. This depends on the Desktop Environment and what file manager you wish to use by default. Many Desktop Environments have an option to name global default applications, like a default browser, default mail program and default file manager. Look for it in the desktop environment settings.
If otherwise you wish to do this manually, I will need to create the default application association by using a command such as
$ xdg-mime default <name.desktop> inode/directory. For this to work a
.desktopfile for the application you wish to use must already exist in
~/.local/share/applications/. If you don’t have such a file, it needs to be created. In that case, open any other
.desktopfile in that directory in your editor to have an idea of their format. And get also help from the XDG Specification.
It would be interesting to know what unit is this that is actually delaying the shutdown process.
First make sure you are running with persistent logging:
/etc/systemd/journald.confshould have the
Storageproperty set to
persistent. Or it should have it commented.
- you should have or
With this, when you boot back up after one of those delayed shutdowns, you can run “journalctl -rb -1” to show the log of the last session in reverse chronological order (most recent at the top). Hopefully you may be able to spot the troublemaker, if not by message, by the timestamp differences.
That changes it all. And in light of the information below, PacBang must simply not be creating a valid utmp.
man utmpwhich you should also read. It explains which processes create the file on boot and which maintain it. It also explains why xterm is working. It actually maintains the file. And in doing so, it certainly fixes whatever is wrong in the original struct created by PacBang installed tools. Because terminal emulators are not required to perform this maintenance task, those who don’t fail.
PacBang is over an year old. Last version is from April last year and it has been abandoned. So I would really suggest dropping it. It clearly needs maintenance. But if you want to keep using it, to fix this bug you’ll need to somehow update its base packages. The culprit must be within the base group, likely the
util-linuxpackage which contains agetty and utmpdump, among other things. The certainly much older systemd version it ships with may also be the problem. From my understanding PacBang was an offline installer. Correct?
Mighty weird. I’m particularly dumbstruck by why would not ALL the terminals fail. You see, from all I know,
/var/run/utmpis generated by root at boot. It has got nothing to do with bash configuration files (which you just confirmed to me). And for the most part of normal computer operations, utmp remains unchanged throughout the session.
I’m not sure I can help any further. Or that I even understand the nature of the problem. In any case, here’s my utmp stat. Hope this helps somehow:
$ ls -l /var/run/utmp -rw-rw-r-- 1 root utmp 768 Oct 17 10:51 /var/run/utmp