SUMMARY If the blocking of outgoing traffic using the rule in iptables is enabled: sudo iptables -I OUTPUT -m owner --uid-owner your_user_name -j DROP then when you open the image in the file manager using gwenviev, it does not open, but freezes for 3 minutes or longer. STEPS TO REPRODUCE 1. run in terminal: sudo iptables -I OUTPUT -m owner --uid-owner your_user_name -j DROP 2. go to the image directory in the file manager 3. open image with gwenviev OBSERVED RESULT Nothing will happen for at least 3 minutes. In the list of processes the process of gwenviev will be visible. EXPECTED RESULT Gvenviev should open immediately and show the image SOFTWARE/OS VERSIONS Linux/KDE Plasma: this behaves like this on all distributions and shells that I used: Kubuntu 18.04.2 64-bit UbuntuStudio 18.04.2 64-bit UbuntuStudio 19.10 64-bit Xubuntu 19.10 64-bit Xubuntu 19.10 64-bit with Plasma Xubuntu 19.10 64-bit with Mate ADDITIONAL INFORMATION If, during the operation of the firewall blocking rule, you start the Gwenviev file manager and not through the shortcut in the application menu, it will open immediately, but when you try to go to the image directory, it will freeze for the same 3 minutes. This is a very critical bug for me. I use this rule to block traffic and because of this I can not normally use gwenviev as a default image viewer. To use them I have to disconnect the network and delete the blocking rule.
Can you get a backtrace to see where it's blocking?
(In reply to Kai Uwe Broulik from comment #1) > Can you get a backtrace to see where it's blocking? Sorry, I don’t understand what trace we are talking about. If you say how to do it, I will.
Solution found. I had a similar problem with Ardour. https://tracker.ardour.org/view.php?id=8160 Apparently Gwenview also uses a localhost for some operations. You need to add permission for outgoing traffic to the localhost: -A OUTPUT -d 127.0.0.1 -j ACCEPT