I am well aware of the Unix Domain socket issue with Geany and `sudo` discussed at length in #1411 and reported by users in #294, #1411, and #1615. However, prior discussion has focused on what Geany's behavior should be when invoked with `sudo` and how users can resolve the issue.
**This situation, where a file in Geany's configuration is invalid for whatever reason, is one that Geany should more facilitate a more graceful recovery from.** Requiring the user to search the internet to discover how to fix the problem, and then having them need to manually delete a configuration file is not a satisfactory user experience.
Specifically, I would suggest that the dialog [found in the code here](https://github.com/geany/geany/blob/935c16ea25374d323ec4212a1a49bdce68d4603b...) should be modified to include an option for Geany itself to delete the problematic socket (`~/.config/geany/geany_socket_*`), including the potential consequences of this action.
Two problems with that:
1. how does Geany know if the socket is a leftover, or if that instance of Geany is still running?
2. if the socket is created by Geany running as root then Geany running as user can't delete it.
Well, IMO again, it's really a distribution's `sudo` configuration issue. In no circumstances should applications be left to believe that a directory is the current user's home if it shouldn't be considered as such. The issue you describe can only happen with a badly configured `sudo`, or somebody willingly setting some specific environment variable to point in another user's directory, and still have write permission there. Meh.
This said, maybe altering the dialog to suggest where to look could be fine I guess. Offering to automatically recover seems useless and potentially dangerous to me, given what can actually lead to this situation -- e.g., no reasonable usage.
2. if the socket is created by Geany running as root then Geany running as user can't delete it.
That's not necessarily true: if the user has write permission on the directory containing the file it can delete that file.
Thinking about it some more, since `su` is a Linux thing, and on Linux the thing in the config is a link, not the actual socket which is a tempfile somewhere. Removing the link won't affect the other Geany, just nobody will be able to communicate with it after that since they can't find the temp file.
@b4n, but a better idea might be to include the effective UID in the socket link name. Then it won't matter.
@elextr It sounds like you're proposing a fix which will prevent this Geany mis-configuration from occurring, regardless of how `sudo` is configured. I suggest that discussion about such a fix should go elsewhere, probably at #1411. While a decision to follow your proposal would make this obsolete, given that this has been an issue [since at least 2014](https://github.com/geany/geany/issues/294#issue-36252042), it seems reasonable to me that a fix be implemented in the meantime.
I'm proposing that regardless of what is decided about #1411, Geany should facilitate recovery from configuration problems. While this one seems to always be due to the `sudo` issue, mis-configuration can occur due to system crashes, users messing with files, Geany upgrades, etc. I think it's appropriate for software to try to help users with these kinds of issues recover from the problem.
As far as practical implementation, Geany could try to detect if there actually is a configuration problem. It could do this be checking: 1. If the socket file (~/.config/geany/geany_socket*) is a symlink to a non-existent file. (Probably the best method) 2. If there is a currently running process named geany (eg. `ps -A |grep geany`). Obviously, it would need to ignore the currently running Geany process.
Note that this issue detection step need not be 100% accurate. The dialog could make a recommendation accordingly, eg. "There doesn't appear to be a running instance of Geany, but it is possible that it is aliased somehow. Please delete the socket link *only* if you are sure that Geany isn't currently running."
Alternately, Geany could offer to delete the file without doing any checking whatsoever. The warning in this case might read, "Only delete this file if you continue to experience this error after restarting your system." Y'all know the risks better than I do; explain them to users as you see fit.
The problem at #1411 is more than just the root problem since its involving a foreign filesystem as well, and since few people seem to have that setup to care or develop or test it, nothing has happened for several years.
Best to keep this separate for the best chance of someone doing something, and in the process it can solve part of #1411.
Adding the effective UID to the link name and testing the ownership of the socket, not the link seems fairly simple and somebody might contribute it test it and accept it.
All other "recovery" methods are more complex and less likely to happen.
In fact most of the regular contributors seem to be of the opinion that there are more useful things to spend time on than occasional problems caused by someone else's misconfiguration.
github-comments@lists.geany.org