Results 1 to 5 of 5

Thread: Difference in how openSUSE treats opening a new shell

  1. #1

    Default Difference in how openSUSE treats opening a new shell

    I'm having an issue with the Cisco Anyconnect VPN client that seems to be related to how openSUSE handles a user opening a new shell. If I create a new shell by (1) starting gnome-terminal, (2) opening a new tab in gnome-terminal, (3) logging in over SSH, or (4) starting XTerm, the VPN client treats this as a user log-out event and disconnects the VPN session. Any action that creates a new shell in the system causes this. Starting a new instance of bash or zsh in an existing terminal does *not* cause this behavior. However, this issue does *not* reproduce on any other distro I've tried, including Fedora, Arch, Debian, and Ubuntu. I can only reproduce it on openSUSE 13.2 and Tumbleweed. Does anyone know the differences between openSUSE and other distros when it comes to handling a new shell instance?

    What I've tried:


    • Different shells (bash, sh, zsh, csh)
    • Different GUIs (gnome-terminal, XTerm, VT login)
    • Removing /etc/profile, /etc/profile.d, and /etc/bash.bashrc (to see if it was something with the login scripts)
    • Replacing /bin/bash with a copy from a Ubuntu system that does not have this problem



    And yes, I know openconnect is an option, but this issue is bugging me and I want to find a solution.

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,504
    Blog Entries
    3

    Default Re: Difference in how openSUSE treats opening a new shell

    Quote Originally Posted by jholewinski View Post
    Does anyone know the differences between openSUSE and other distros when it comes to handling a new shell instance?
    There are no important differences that I am aware of.

    Try the following from an already open terminal:
    Code:
    ( xterm & )
    ( xterm -ut &)
    ( xterm +ut & )
    Do those one at at time, and see which disconnect the VPN.

    The first of those opens an xterm with defaults.
    The second opens an xterm, but tells it to not add a line to "utmp"
    The third insists that it should add a line to "utmp" (probably the same as the default).

    I'm just guessing that maybe something in the VPN software is monitoring "utmp". This would be a way of testing.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  3. #3

    Default Re: Difference in how openSUSE treats opening a new shell

    Interesting! Opening a new shell with "xterm -ut" does seem to work. Thanks for the info! So it does appear to be related to utmp, though I'm still curious why this is only an issue on openSUSE.

  4. #4

    Default Re: Difference in how openSUSE treats opening a new shell

    So it's definitely an issue with watching /var/run/utmp. I can work around the issue by LD_PRELOAD'ing an .so that replaces inotify_init() with a dummy stub. The VPN client can no longer register an inotify watcher on /var/run/utmp.

    But I'm still confused on the real issue: what about utmp is different with openSUSE? I just compared /var/run/utmp on two machines, one openSUSE and another Fedora, before and after opening a new tab in gnome-terminal. In both cases, one line is added to utmp, and the only difference is the login time, pts/#, and login PID. So there has to be more to it.

    But I have a work around now, so I'm happy!

    Thanks again!

  5. #5
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,504
    Blog Entries
    3

    Default Re: Difference in how openSUSE treats opening a new shell

    Quote Originally Posted by jholewinski View Post
    But I'm still confused on the real issue: what about utmp is different with openSUSE?
    It might be a difference in libraries somewhere. There's possibly a compile time option that opensuse is using but fedora and ubuntu are not using.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •