Rerunning the VPN .run file every time? That is the installer

You double-click the file you downloaded last week, the connection works, and the habit sticks: every time the VPN drops, you run that same file again. Nothing breaks immediately, which is why the pattern survives. What you are actually doing is reinstalling the application over itself, then opening it again from the end of the installer.

Once the installer finishes, the program lives somewhere else on the disk and has its own icon, its own settings and its own background service. The download was the delivery mechanism, and keeping it around is fine, but it is not the thing you connect with.

What the download actually put on the disk

A .run file is a naming convention, not a file type. It can be a shell script, a self-extracting archive, a compiled binary, or something that decides at runtime which of those to be. The suffix tells you nothing about who published it or whether you should trust it, which is the reason installation instructions start with obtaining it from a verified channel rather than with a command.

For a vendor that ships this way, the installer unpacks its payload, writes the application and its supporting files, and registers what it needs with the desktop. When it finishes, the interesting artifacts are the application binary, a desktop entry, and often a service the application starts. None of those is the file you downloaded. Look in the directory the installer names in its final output and you will see the distinction immediately.

The habit of rerunning it also hides a diagnosis. If the app opens after a full reinstall but not from the menu, you learn nothing about which piece was missing, because the installer rebuilt all of them.

Install once, using the vendor's own invocation

Follow the documented invocation exactly, including the interpreter it names. For PIA's Linux client the guide calls the installer through sh, so the command shape is the interpreter followed by the file you actually downloaded.

sh ./pia-linux-VERSION.run

VERSION is a placeholder for whichever build you fetched, not a recommendation to hunt for a specific number. Treat that command as code execution with system-level consequences, because that is what it is: it is not a way to inspect the file, and running it twice does not teach you anything the first run did not.

One detail from that same guide is easy to skip and worth repeating: do not prefix the installer with sudo. It asks for the administrative authorization it needs on its own, and wrapping it in a root shell changes which user's environment the installation lands in. The same reasoning is why "make every download executable and run it" is not a general rule; asking an interpreter to read a script and executing a file directly are different operations with different failure modes.

When the installer completes, the vendor documents signing in and connecting through the application it just installed. Every later connection belongs there. If you are still typing the installer path to get online, you have made the installer part of your workflow by accident.

Launcher, store and tray are three different places

The application menu, a software-store catalogue and the tray area are separate interfaces maintained by different components, and an installer can populate one without touching the others. A standalone installer commonly writes a desktop entry, which is launcher integration and nothing more. It does not make the app a catalogue-managed store installation, and it does not guarantee a tray icon.

A tray indicator needs support from both sides: the running application has to export one, and the desktop has to provide a host for it. On desktops that removed the traditional tray, an app that expects one can run perfectly and show nothing, and that is an integration gap rather than a failed installation. Reporting the desktop version and the app version is what makes that gap actionable.

So when the app opens but the icon is missing, do not reinstall. Check whether a process is running, whether the window is hidden behind a background start, and whether the desktop supports indicators of that kind at all. A missing indicator on a desktop without a tray host is expected behaviour, not a fault. Reinstalling the same download a fifth time only refreshes what already worked.

Record the owner of the install

Write down which channel installed the application, which component updates it, and what removes it. Those three answers are usually not the same program, and a machine where nobody knows them is a machine where two copies of a VPN client eventually fight over the same routes.

Deleting the downloaded installer is not uninstalling anything, and closing the window does not necessarily stop the service or the blocking policy it installed. Before you clean up, find out what runs at login and what survives a reboot.

Once the installer has done its job, put it in a folder you will remember and stop treating it as the application. The next time the tunnel misbehaves, start from the installed app, and let the download stay an artifact of the day you installed it. The PIA Linux installation guide is the reference for the invocation and first-launch steps described above.