Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#471 socket instance often ignored

None
closed-wont-fix
nobody
General (289)
Unknown
5
2014-08-16
2010-04-11
IgnorantGuru
No

geany will sometimes ignore an existing socket/instance and will open a file in a new instance.

One way to consistently trigger this:
# Open a root instance
gksu geany atextfile &
# Open a normal user instance
geany anothertextfile &
# Now manually CLOSE the root instance window
# Now open another file as normal user
geany yetanothertextfile &

yetanothertextfile will be opened as a new instance instead of reusing the existing socket.

Part of this behavior may be related to this bug...
https://sourceforge.net/tracker/?func=detail&aid=2985442&group_id=153444&atid=787791

Arch Linux x64 geany 0.18.1-1 running under Openbox

Discussion

  • Enrico Tröger
    Enrico Tröger
    2010-04-11

    Without having it tested yet, I guess after closing the root instance, the socket doesn't work anymore because the file permissions have changed and it is owned by root. Not completely sure, needs to be tested.
    If so, this is as invalid as the other mentioned report.

    Just don't use Geany as root, thanks.

     
  • IgnorantGuru
    IgnorantGuru
    2010-04-11

    No, the file permissions on the socket don't appear to change. I have also seen it ignore an existing socket under other conditions, such as after a long time has passed.

    Kind of strange to suggest not using a text editor as root as a solution. root is a valid user on a linux system, geany runs as root and works fine in general, so I would suggest correcting this socket problem. Multiple users, including root, should be able to have instances open without them interfering with one another. All similar editors I have used in linux (eg Kate, Bluefish) work as root.

     
  • Enrico Tröger
    Enrico Tröger
    2010-04-18

    I gave this issue a deeper look although I still think you shouldn't run Geany as root. But the real problem isn't strictly related to root and file permissions, but to the way you use (gk)su.

    I reproduced the problem in a root shell after getting root with: 'su'. Then the uid changes to 0 but the whole environment with all the variables keeps this of the previous user. So, most importantly for Geany, the environment variable $XDG_CONFIG_HOME keeps their old value, this is of the previous user. And this is the Geany session started as root connects to the already existing one of the previous user.

    When a second instance of Geany is started, it looks in the configuration directory for a Unix Domain Socket and sends the filename to it to open it. The configuration directory is determined using the GLib function g_get_user_dir() which in turn uses the environment variable $XDG_CONFIG_HOME. And this is why the root Geany instance connects to the wrong instance because it uses the wrong configuration directory.
    One could argue who is at fault at this point.
    I would say it is (gk)su which doesn't clean the environment. Though from the su point of view, this is intended and so correct behaviour. And there is, from the su point of view, an easy solution:
    'su -'
    which starts a completely clean session for root with the correct environment and from within such a session Geany starts probably a new instance as root with the requested file.

    Now we know what's happening.
    I personally would consider suggesting using 'su -' to start a login shell as a different user and then spawn Geany an acceptable solution. What about you?

    Thinking about handling this whole scenario in Geany would technically maybe possible by checking the uid and maybe the effective user id of the user and then maybe ignore the $XDG_CONFIG_HOME variable but I think this would be a bit hackish.

     
  • IgnorantGuru
    IgnorantGuru
    2010-04-18

    Thanks for looking at this and for the info. That's good to know as a workaround - perhaps I can just clear or change $XDG_CONFIG_HOME before running gksu. That also explains why the root user didn't seem to have separate config settings. But I think it would be more correct behavior for Geany to know what user is running it, and only use sockets owned by that user. I have not encountered this problem with any other editors, file managers, etc., so I think that behavior would be more consistent. Root user should not use sockets that don't belong to it.

    As you know, only a shortcut to the socket is located in the home config dir, with the actual socket being in /tmp. Perhaps it could just look in /tmp for a socket belonging to the current user.

    Really, the root user should have its own geany config in /root/.config/geany. That again would be more consistent - /root being root's home. That would also solve the socket problem. If you really don't want geany running as root, having it respawn as another user would be the correct solution, but I don't suggest that. Geany's features make it a very convenient system file editor, and it runs fine as root in general. Maybe just make a special exception when the user is root and ignore $XDG_CONFIG_HOME in that case. That would solve both the socket and the root config issues. I don't think that's hackish. It's more hackish to have to manually change $XDG_CONFIG_HOME or run su -.

     
  • Enrico Tröger
    Enrico Tröger
    2010-04-19

    In SVN, I implemented a rudimentary check of the user id of the running process (in your case 0) against the ownership of the socket file (in your case the uid of your user).
    This should prevent the cases where the uid is different but the XDG_CONFIG_HOME variable is set to another home dir, the 'su' case.
    In he current implementation, Geany will show an error dialog and then quit. There is no way to get it started this way.

    I guess this is not what you want, understandably.
    I disagree that ignoring the XDG_CONFIG_HOME variable is a solution. And I also disagree with "it's more hackish to use 'su -'. I really think this would be the cleanest way.

    Anyway, ideas are welcome.

     
  • IgnorantGuru
    IgnorantGuru
    2010-04-20

    I can confirm that the following is a workaround for 0.18.1:
    gksu XDG_CONFIG_HOME=/root/.config geany

    The way geany is now, if a user runs it with su, it writes root files to the user's home folder, which IMO is broken behavior, and is at variance with the way other programs handle this. At any rate I think it would be worth exploring how other programs handle this issue. Perhaps they use $HOME in root's case, which su does set to /root. Anyway, thanks for the info.

     
  • Enrico Tröger
    Enrico Tröger
    2010-04-27

    Not sure what to do, really.
    It's weird 'su' sets $HOME but not $LOGNAME nor the other environment variables.

    I still would think using 'su -' is the cleanest way.

    And yes, it would be interesting how other applications handle this case.

     
  • Lex Trotman
    Lex Trotman
    2012-09-14

    Geany should use the environment as given, its not up to Geany to try to second guess what environment the user intended.

    Geany will refuse to use a socket owned by another user to prevent interrupting someone else's session.

     
  • Lex Trotman
    Lex Trotman
    2012-09-14

    • status: open --> pending-wont-fix
     
    • status: pending-wont-fix --> closed-wont-fix
    • Found in: --> Unknown
    • Fixed in: --> None