openvpn process locks up after sleep

[Testy Tester]

Apologies in advance for the incompleteness of this bug report; I'll fill in more data as I get it.

For the last N weeks I've been noticing a problem: When my mac wakes from sleep, the openvpn process is locked up in some way, which in turn causes the mouse to turn into a pinwheel when it hovers over the tunnelblick menubar icon. In this state the tunnel is down. "kill <pid>" on the openvpn process has no effect, but "kill -9 <pid>" works. About five seconds after that, the menubar icon stops pinwheeling and becomes responsive again.

There were no configuration changes made for more than a year when this problem started happening. It is possible that an Apple security update was applied just before, but I don't think so. (Sorry, my memory as to when this started exactly is cloudy. It didn't seem significant until it had happened a number of times.)

For a while I was too jammed up with work projects to look into this much, as I had a functional workaround. But it's seriously annoying, and still not fixed, so I just started looking into it more. I regret that I did not note when it started up exactly, so my first step has been to try to figure out when things went wrong. I was staying on current betas all this time, but I reverted to the latest release (3.8.7a), which did not help. I then reverted to 3.8.6a, and so far I have not seen it happen again. It's only been a few days so this could be coincidental, but I'm fairly sure not. If I don't see it again by the end of the week I'll be 100% certain - the bug didn't happen always, but it definitely happened more than half the time. Obviously staying on 3.8.6a is not a feasible long-term solution, though.

This system is a 2012 MBP 15" running the most recent version of high sierra with all updates applied. I don't believe any such updates have come out since before this bug appeared.

I'm willing to help debug this in any reasonable way, including running test builds. Let me know what you need.

Here's an example of the process when stuck. I note that the "Ss" state (which is always the case) suggests that it's in fact getting some cycles and doing something, though not much, as it never has much CPU time racked up:

root             29976   0.0  0.0  4317880    732   ??  Ss   12:01PM   0:00.01 /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.5.4-openssl-1.1.1l/openvpn --daemon --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Sxxxxxx-SLibrary-SApplication Support-STunnelblick-SConfigurations-STEST xxxxx (xxx xxxxxx + xxxxxxxx).tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_1098032.54522.openvpn.log --cd /Library/Application Support/Tunnelblick/Users/xxxxxx/TEST xxxxx (xxx xxxxxx + xxxxxxxx).tblk/Contents/Resources --machine-readable-output --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5770 3.8.7a (build 5770)" --verb 3 --config /Library/Application Support/Tunnelblick/Users/xxxxxx/TEST xxxxx (xxx xxxxxx + xxxxxxxx).tblk/Contents/Resources/config.ovpn --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/xxxxxx/TEST xxxxx (xxx xxxxxx + xxxxxxxx).tblk/Contents/Resources --verb 3 --cd /Library/Application Support/Tunnelblick/Users/xxxxxx/TEST xxxxx (xxx xxxxxx + xxxxxxxx).tblk/Contents/Resources --management 127.0.0.1 54522 /Library/Application Support/Tunnelblick/Mips/TEST xxxxx (xxx xxxxxx + xxxxxxxx).tblk.mip --management-query-passwords --management-hold --script-security 2 --route-up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw

Thanks!

[Tunnelblick developer]

Have you tried un-checking "Disconnect when computer goes to sleep" in the "Advanced" settings window?

[Testy Tester]

I have not. I can do that and report back, do you want me to?

In the meantime, 3.8.6a continues to work well and I'm 90% sure it doesn't have the bug, which means that this issue was introduced between 3.8.6a and 3.8.7a. If you'd like to send me some intermediate builds (or links to them), for a somewhat manual bisection, I'm game to try them.

[Tunnelblick developer]

Yes, please try with that checkbox un-checked and report back.

[Testy Tester]

So, turning off that check box does NOT fix the bug. It sometimes hides it, in that the VPN generally goes down (presumably due to missed keepalives or some other timeout issue) when the machine sleeps. In that case, I just have to bring up the VPN as normal. However, sometimes the VPN doesn't go down, and then things are just locked as I said before.

BTW, as I think about it now, I'm not at all confident the title I gave this thread is accurate. *Something* is locked, but it may not be openvpn. That was an assumption I shouldn't have made.

[Tunnelblick developer]

Under certain circumstances, OpenVPN attempts to reconnect the VPN hundreds of thousands of times per second, logging each request. That overwhelms Tunnelblick's ability to display the log, and results in the cursor changing to a colored pinwheel when you hover it over the Tunnelblick icon (or any open Tunnelblick window). It isn't clear what causes the too rapid reconnect requests: a bug in OpenVPN, and/or a misconfiguration of the OpenVPN configuration file, and/or settings "pushed" by the VPN server. (This happens only rarely, from what I can tell, so it isn't a priority for me to modify Tunnelblick to cope with such a huge amount of logging data.)

To see if that's the situation, you can disable logging (set "VPN log level" to "No OpenVPN or Tunnelblick VPN logging"). Then disconnect and reconnect the VPN to apply the setting. (The setting change doesn't take effect until the next time the VPN is connected.)

If the problem still happens, then please use /Applications/Utilities/Activity Monitor to get a "Spindump" of the Tunnelblick process and post the result.

[Testy Tester]

OK, done. I've completely disabled logging and reenabled "disconnect on sleep" since that's already known not to be relevant. However... unless the logging behavior you're describing is new since 3.8.6a, it's a waste of time, as this bug definitely doesn't exist in 3.8.6a.

FWIW, the config file is extremely vanilla and simple. I can post it if you like.

[Testy Tester]

Disabling logging made no difference. 3.8.7a still locks up.

I have taken the spindump. it appears to be a stack trace of every thread/process in the system... weird. (Along with a few other miscellaneous things like a kext status display.)

Here's the trace for Tunnelblick's and openvpn's threads. The whole spindump is probably way too big to post but I've saved a copy, so if you need specific other threads (kernel threads like ifnet_start_utun0, for example) let me know and I can post them too. I also sampled the Tunnelblick process, though I don't know if that's any more useful.

Thanks!

Date/Time:       2022-01-04 12:14:03 -0500
OS Version:      Mac OS X 10.13.6 (Build 17G14042)
Architecture:    x86_64
Report Version:  26

Data Source:     Stackshots

Command:         Tunnelblick
Path:            /Applications/Tunnelblick.app/Contents/MacOS/Tunnelblick
Identifier:      net.tunnelblick.tunnelblick
Version:         3.8.7a (build 5770) (5770)
Parent:          launchd [1]
PID:             39974

Duration:        9.98s (process was unresponsive for 4085 seconds before sampling)
Steps:           923 (10ms sampling interval)

Hardware model:  MacBookPro10,1
Active cpus:     8

Time Awake Since Boot: 790000s
Time Since Wake: 1700s

Fan speed:       2163 rpm

----------------------------------------
Heavy format: stacks are sorted by count
----------------------------------------



Process:         Tunnelblick [39974]
Path:            /Applications/Tunnelblick.app/Contents/MacOS/Tunnelblick
Architecture:    x86_64
Parent:          launchd [1]
UID:             501
Task size:       55.81 MB (+48 KB)
CPU Time:        0.213s (350.7M cycles, 153.1M instructions, 2.29c/i)
Note:            Unresponsive for 4085 seconds before sampling
Note:            2 idle work queue threads omitted

  Thread 0xabb63e           DispatchQueue 1           923 samples (1-923)       priority 46 (base 46)     cpu time 0.213s (350.1M cycles, 153.0M instructions, 2.29c/i)
  923  start + 1 (libdyld.dylib + 4117) [0x7fff5e7b6015]
    923  main + 34 (Tunnelblick + 6658) [0x106b4ba02]
      923  NSApplicationMain + 804 (AppKit + 23098) [0x7fff33ca5a3a]
        923  -[NSApplication run] + 764 (AppKit + 223309) [0x7fff33cd684d]
          923  -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 (AppKit + 8224308) [0x7fff34477e34]
            923  _DPSNextEvent + 2085 (AppKit + 268859) [0x7fff33ce1a3b]
              923  _BlockUntilNextEventMatchingListInModeWithFilter + 64 (HIToolbox + 194692) [0x7fff35a34884]
                923  ReceiveNextEventCommon + 613 (HIToolbox + 195334) [0x7fff35a34b06]
                  923  RunCurrentEventLoopInMode + 286 (HIToolbox + 195990) [0x7fff35a34d96]
                    923  CFRunLoopRunSpecific + 487 (CoreFoundation + 530311) [0x7fff36754787]
                      923  __CFRunLoopRun + 1293 (CoreFoundation + 532269) [0x7fff36754f2d]
                        923  __CFRunLoopDoSources0 + 208 (CoreFoundation + 535216) [0x7fff36755ab0]
                          923  __CFRunLoopDoSource0 + 108 (CoreFoundation + 1408604) [0x7fff3682ae5c]
                            923  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 654081) [0x7fff36772b01]
                              923  __NSThreadPerformPerform + 334 (Foundation + 428373) [0x7fff388b7955]
                                923  -[MenuController didBecomeInactiveUser] + 1329 (Tunnelblick + 272817) [0x106b8c9b1]
                                  903  -[MenuController waitForDisconnection:] + 801 (Tunnelblick + 184801) [0x106b771e1]
                                    903  usleep + 53 (libsystem_c.dylib + 509464) [0x7fff5e881618]
                                      903  __semwait_signal + 10 (libsystem_kernel.dylib + 118146) [0x7fff5e906d82]
                                       *903  semaphore_wait_continue + 0 (kernel + 593936) [0xffffff8000291010]
                                  20   -[MenuController waitForDisconnection:] + 470 (Tunnelblick + 184470) [0x106b77096]
                                    20   -[VPNConnection noOpenvpnProcess] + 71 (Tunnelblick + 106871) [0x106b64177]
                                      20   -[NSApplication(LoginItem) pIdsForOpenVPNProcessesOnlyMain:] + 224 (Tunnelblick + 303568) [0x106b941d0]
                                        20   __sysctl + 10 (libsystem_kernel.dylib + 118986) [0x7fff5e9070ca]
                                         *20   hndl_unix_scall64 + 22 (kernel + 120390) [0xffffff800021d646]
                                           *20   unix_syscall64 + 616 (kernel + 6301720) [0xffffff8000802818]
                                             *20   sysctl + 417 (kernel + 5445793) [0xffffff80007318a1]
                                               *20   ??? (kernel + 5445238) [0xffffff8000731676]
                                                 *20   ??? (kernel + 5429420) [0xffffff800072d8ac]
                                                   *13   proc_iterate + 758 (kernel + 5372822) [0xffffff800071fb96]
                                                     *3    sysdoproc_callback + 765 (kernel + 5430317) [0xffffff800072dc2d]
                                                       *2    kauth_cred_proc_ref + 25 (kernel + 5146569) [0xffffff80006e87c9]
                                                         *1    lck_mtx_lock + 44 (kernel + 112812) [0xffffff800021b8ac] (running)
                                                         *1    lck_mtx_lock + 132 (kernel + 112900) [0xffffff800021b904] (running)
                                                       *1    kauth_cred_proc_ref + 103 (kernel + 5146647) [0xffffff80006e8817]
                                                         *1    lck_mtx_unlock + 71 (kernel + 114375) [0xffffff800021bec7] (running)
                                                     *2    sysdoproc_callback + 664 (kernel + 5430216) [0xffffff800072dbc8]
                                                       *1    proc_pgrp + 34 (kernel + 5365106) [0xffffff800071dd72]
                                                         *1    lck_mtx_lock + 44 (kernel + 112812) [0xffffff800021b8ac] (running)
                                                       *1    proc_pgrp + 160 (kernel + 5365232) [0xffffff800071ddf0]
                                                         *1    lck_mtx_unlock + 71 (kernel + 114375) [0xffffff800021bec7] (running)
                                                     *2    sysdoproc_callback + 1031 (kernel + 5430583) [0xffffff800072dd37]
                                                       *1    kauth_cred_unref + 22 (kernel + 5157958) [0xffffff80006eb446]
                                                         *1    lck_mtx_lock + 4 (kernel + 112772) [0xffffff800021b884] (running)
                                                       *1    kauth_cred_unref + 30 (kernel + 5157966) [0xffffff80006eb44e]
                                                         *1    ??? (kernel + 5158128) [0xffffff80006eb4f0] (running)
                                                     *2    sysdoproc_callback + 1947 (kernel + 5431499) [0xffffff800072e0cb]
                                                       *1    ??? (kernel + 1559884) [0xffffff800037cd4c] (running)
                                                       *1    ??? (kernel + 1560037) [0xffffff800037cde5] (running)
                                                     *1    bcopy + 25 (kernel + 18446744073709105305) [0xffffff8000193099] (running)
                                                     *1    sysdoproc_callback + 649 (kernel + 5430201) [0xffffff800072dbb9] (running)
                                                     *1    sysdoproc_callback + 1022 (kernel + 5430574) [0xffffff800072dd2e] (running)
                                                     *1    sysdoproc_callback + 1914 (kernel + 5431466) [0xffffff800072e0aa]
                                                       *1    pg_rele + 29 (kernel + 5363741) [0xffffff800071d81d] (running)
                                                   *4    proc_iterate + 791 (kernel + 5372855) [0xffffff800071fbb7]
                                                     *4    proc_rele + 21 (kernel + 5358645) [0xffffff800071c435]
                                                       *3    lck_mtx_lock + 44 (kernel + 112812) [0xffffff800021b8ac] (running)
                                                       *1    lck_mtx_lock + 69 (kernel + 112837) [0xffffff800021b8c5] (running)
                                                   *1    proc_iterate + 525 (kernel + 5372589) [0xffffff800071faad] (running)
                                                   *1    proc_iterate + 532 (kernel + 5372596) [0xffffff800071fab4] (running)
                                                   *1    proc_iterate + 748 (kernel + 5372812) [0xffffff800071fb8c]
                                                     *1    proc_transwait + 133 (kernel + 5369589) [0xffffff800071eef5]
                                                       *1    lck_mtx_unlock + 71 (kernel + 114375) [0xffffff800021bec7] (running)

  Thread 0xabb67e           Thread name "com.apple.NSURLConnectionLoader"       923 samples (1-923)       priority 31 (base 31)
  923  <truncated backtrace>
    923  __CFRunLoopRun + 1783 (CoreFoundation + 532759) [0x7fff36755117]
      923  __CFRunLoopServiceMachPort + 341 (CoreFoundation + 536005) [0x7fff36755dc5]
        923  mach_msg_trap + 10 (libsystem_kernel.dylib + 78330) [0x7fff5e8fd1fa]
         *923  ipc_mqueue_receive_continue + 0 (kernel + 334192) [0xffffff8000251970]

  Thread 0xabb6c1           Thread name "com.apple.NSEventThread"               923 samples (1-923)       priority 46 (base 46)
  923  thread_start + 13 (libsystem_pthread.dylib + 11257) [0x7fff5eacdbf9]
    923  _pthread_start + 377 (libsystem_pthread.dylib + 13581) [0x7fff5eace50d]
      923  _pthread_body + 340 (libsystem_pthread.dylib + 13921) [0x7fff5eace661]
        923  _NSEventThread + 184 (AppKit + 1568708) [0x7fff33e1efc4]
          923  CFRunLoopRunSpecific + 487 (CoreFoundation + 530311) [0x7fff36754787]
            923  __CFRunLoopRun + 1783 (CoreFoundation + 532759) [0x7fff36755117]
              923  __CFRunLoopServiceMachPort + 341 (CoreFoundation + 536005) [0x7fff36755dc5]
                923  mach_msg_trap + 10 (libsystem_kernel.dylib + 78330) [0x7fff5e8fd1fa]
                 *923  ipc_mqueue_receive_continue + 0 (kernel + 334192) [0xffffff8000251970]

  Thread 0xabb6f7           923 samples (1-923)       priority 37 (base 37)
  923  <truncated backtrace>
    923  __psynch_cvwait + 10 (libsystem_kernel.dylib + 117270) [0x7fff5e906a16]
     *923  psynch_cvcontinue + 0 (pthread + 38948) [0xffffff7f82dc6824]

  Thread 0xabb79f           Thread name "com.apple.CFSocket.private"            923 samples (1-923)       priority 46 (base 46)
  923  thread_start + 13 (libsystem_pthread.dylib + 11257) [0x7fff5eacdbf9]
    923  _pthread_start + 377 (libsystem_pthread.dylib + 13581) [0x7fff5eace50d]
      923  _pthread_body + 340 (libsystem_pthread.dylib + 13921) [0x7fff5eace661]
        923  __select + 10 (libsystem_kernel.dylib + 118002) [0x7fff5e906cf2]
         *923  ??? (kernel + 5427296) [0xffffff800072d060]

  Binary Images:
           0x106b4a000 -        0x106c6dfff  net.tunnelblick.tunnelblick 3.8.7a (build 5770) (5770) <0F09AD49-8CF2-3469-9361-B624EDE345D5>  /Applications/Tunnelblick.app/Contents/MacOS/Tunnelblick
        0x7fff33ca0000 -     0x7fff34afefff  com.apple.AppKit 6.9 (1561.61.100)                     <4E6EA3FA-8C2C-3B21-BFF9-6F8C458B7BE1>  /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
        0x7fff35a05000 -     0x7fff35d0afff  com.apple.HIToolbox 2.1.1 (911.10)                     <8D2EBE85-9AF0-38BC-ACD3-1ED978643907>  /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
        0x7fff366d3000 -     0x7fff36b6ffff  com.apple.CoreFoundation 6.9 (1455.300)                <D9D5D50D-5DA3-34B6-8077-DD24315A4B1E>  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
        0x7fff3884f000 -     0x7fff38c16fff  com.apple.Foundation 6.9 (1455.300)                    <0479E072-1DD0-3881-A9A2-EDAD3EE58C23>  /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
        0x7fff5e7b5000 -     0x7fff5e7d2fff  libdyld.dylib (551.5)                                  <49ABA86D-DD48-3133-9B14-B9A564EEBC66>  /usr/lib/system/libdyld.dylib
        0x7fff5e805000 -     0x7fff5e88efff  libsystem_c.dylib (1244.50.9)                          <25DD83D8-80CA-3DFF-8626-FE704911F19C>  /usr/lib/system/libsystem_c.dylib
        0x7fff5e8ea000 -     0x7fff5e910fff  libsystem_kernel.dylib (4570.71.82.8)                  <C34BA704-FAFF-3DDB-9827-5930B5BEF134>  /usr/lib/system/libsystem_kernel.dylib
        0x7fff5eacb000 -     0x7fff5ead6fff  libsystem_pthread.dylib (301.50.1)                     <283E64A7-A2B2-3212-95BA-4D21F9AE36CF>  /usr/lib/system/libsystem_pthread.dylib
   *0xffffff7f82dbd000 - 0xffffff7f82dc8fff  com.apple.kec.pthread 1.0 (1)                          <E64F7A49-CBF0-3251-9F02-3655E3B3DD31>  /System/Library/Extensions/pthread.kext/Contents/MacOS/pthread
   *0xffffff8000200000 - 0xffffff80009fffff  kernel (4570.71.82.8)                                  <5E83A13A-32F5-3604-8591-50E2F2F70DC6>  /System/Library/Kernels/kernel

[...]

Process:         openvpn [40154]
Path:            /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.5.4-openssl-1.1.1l/openvpn
Architecture:    x86_64
Parent:          launchd [1]
UID:             -2
Task size:       2832 KB
CPU Time:        <0.001s (740.1K cycles, 110.6K instructions, 6.69c/i)

  Thread 0xabbcb7           DispatchQueue 1           923 samples (1-923)       priority 20 (base 20)     cpu time <0.001s (740.1K cycles, 110.6K instructions, 6.69c/i)
  923  start + 1 (libdyld.dylib + 4117) [0x7fff5e7b6015]
    923  main + 597 (openvpn + 183214) [0x10ae5ebae]
      923  init_instance_handle_signals + 38 (openvpn + 86253) [0x10ae470ed]
        923  init_instance + 401 (openvpn + 86720) [0x10ae472c0]
          923  management_hold + 316 (openvpn + 113524) [0x10ae4db74]
            923  man_standalone_event_loop + 42 (openvpn + 111335) [0x10ae4d2e7]
              923  man_block + 165 (openvpn + 117244) [0x10ae4e9fc]
                923  __select + 10 (libsystem_kernel.dylib + 118002) [0x7fff5e906cf2]
                 *923  ??? (kernel + 5427296) [0xffffff800072d060]

  Binary Images:
           0x10ae32000 -        0x10b055fff  openvpn (0)                           <22A3BF9A-64C6-32D8-865D-90FB0F77B33C>  /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.5.4-openssl-1.1.1l/openvpn
        0x7fff5e7b5000 -     0x7fff5e7d2fff  libdyld.dylib (551.5)                 <49ABA86D-DD48-3133-9B14-B9A564EEBC66>  /usr/lib/system/libdyld.dylib
        0x7fff5e8ea000 -     0x7fff5e910fff  libsystem_kernel.dylib (4570.71.82.8) <C34BA704-FAFF-3DDB-9827-5930B5BEF134>  /usr/lib/system/libsystem_kernel.dylib
   *0xffffff8000200000 - 0xffffff80009fffff  kernel (4570.71.82.8)                 <5E83A13A-32F5-3604-8591-50E2F2F70DC6>  /System/Library/Kernels/kernel

[Tunnelblick developer]

Thanks. I'll look into it. This is not the "too much to log" problem; it is something else – quite possibly a bug in Tunnelblick, not OpenVPN.

[Testy Tester]

Thank you. As I said earlier, this is due to a change after 3.8.6a. If you want to give me one or more builds from between that and 3.8.7a, I can tell you where the bug first shows up, which might be helpful.

[Tunnelblick developer]

What version of OpenVPN and SSL does the configuration use? (I'd first like to completely eliminate OpenVPN as the problem.)

[Testy Tester]

The default for build 5770, so, 2.5.4/1.1.1l.

[Marc Günther]

FWIW, I have exactly the same problem, except that it happens when I switch user accounts.

- Reboot

- login as user A

- establish VPN connection

- switch to user account B

- this launches Tunnelblick in that account, which complains about missing config files and I click on Quit

- logout from B, and log back into A

-> Tunnelblick shows established connection icon, and is unresponsive

Reverting back to 3.8.6a completely fixes this problem, the final result of above actions with that version is:

-> Tunnelblick shows gray icon, and reconnects successfully after some seconds

[Testy Tester]

I too have noticed this when switching between accounts. Except that the second account doesn't even use tunnelblick, so I don't have a second instance trying to start.

[Testy Tester]

You know, unless you have a really good idea of where the new bug is, you could just give me (Marc too if he wants?) a build around 5740 andwe could start bisecting. Shouldn't take too long to narrow down where the change is.

[Tunnelblick developer]

Please try the following versions and report back whether they have the same problem:

• 3.8.7beta01
  
• 3.8.7beta02
  
• 3.8.7beta03
  
• 3.8.7
  

[Testy Tester]

Trying 5730 now, will report within a week.

[Testy Tester]

5730 seems good so far. No lockups. I was hoping to hear from Marc too, but in the meantime, I'll switch to a later build and see if that fails.

[Testy Tester]

5740 (3.8.7b3) DOES HAVE the bug. So I am 95% certain it was introduced somewhere between 5730 and 5740. I have reverted to 5730 for now.

[Testy Tester]

Confirming... 5730 continues to work fine, since my last post.

[Testy Tester]

Still no lockups. Problem was definitely introduced between 5730 and 5740. If you have an intermediate release you'd like me to try, post it here.

[Testy Tester]

Any progress on this? I'm happy to test more versions between 5730 and 5740 if it will help you isolate the bug. I'm blocked from upgrading until this is fixed. :-(

[Testy Tester]

I see that build 5800 is out. Any chance it might fix the bug? I don't see anything in the release notes. If you think it might, I'll try it.

[Tunnelblick developer]

Nothing in the release notes about it means nothing has changed about it.

[Testy Tester]

I recently set up a new M2 Macbook Air, running Ventura (the most recent Beta as of today), and the exact same problem is happening.

[Testy Tester]

Well this is a little interesting... On Ventura, the problem isn't *exactly* the same as High Sierra. But it's close.

In Ventura, I often (but definitely not always) wake my Mac from sleep to find the Tunnelblick menu item pinwheeling endlessly. That part is just like High Sierra. But what's different is, sometimes when that happens, the VPN is still working! And it keeps working for a while, though in at least one case it eventually hung, and I had to restart tunnelblick to bring it back.

This is really puzzling, as I assumed that the menu item was pinwheeling because the openvpn process was hung and not responding to something the menu item was waiting on. But if the process isn't actually hung... then I have no idea what's going on.

It is still true that, as first reported, I can get the menu item to be responsive again by killing the openvpn process.

[Testy Tester]

Well this is interesting. I wrote a little shell script to kill the tunnelblick app and the openvpn process, because I need to do it so often now on Ventura. But today I used it in a terminal window that wasn't root, by accident. So it killed the app (my UID) but not openvpn (root), and relaunched Tunnelblick. To my surprise, not only did Tunnelblick start correctly, but the tunnel from the previous instance of Tunnelblick was recognized, and is working!

That tells me that, at least on Ventura (I'm no longer regularly using High Sierra), openvpn isn't getting stuck. And on High Sierra, Tunnelblick wasn't getting stuck, since killing JUST openvpn would un-pinwheel Tunnelblick. So... what is getting stuck? And what happened to the code between 5730 and 5740 that caused this?

[Testy Tester]

...sigh, this behavior isn't reproducible. With the new script which just kills Tunnelblick, sometimes it works, and sometimes I have to bring the tunnel back up by hand after letting the new tunnelblick kill the old openvpn. Which makes me think I'm hitting two separate issues, maybe.

[Artūrs Soldatovs]

Hello,

"When my mac wakes from sleep, the openvpn process is locked up in some way, which in turn causes the mouse to turn into a pinwheel when it hovers over the tunnelblick menubar icon. About five seconds after that, the menubar icon stops pinwheeling and becomes responsive again."

Have a similar issue as you described, my connection use TAP and I'm on macOS Ventura 13.0 Beta 7 (22A5342f), MacBook Air M1, Tunnelblick 3.8.8beta04 (build 5800).
After sleep, my connection comes back after the scenario as described by Testy Tester. Hanging up wasn't an issue but I notice that after reconnection my working environment crashes on Firefox and I get errors 403 and 500, so even closing the tabs and opening them again it comes back with 403 or 500. The only way to get it working again was close completly Firefox and reopen everything, but not always after Firefox restarted I could get access to all my needed pages, some come back with 403, but after some time they eventually become available. So I was concerned the issue was on the Firefox side and start digging into the issue because I didn't suspect VPN as even it freeze/hangup before reconnection but I can see going him through all steps and gaining connection.

As all my research and experiments didn't succeed on Firefox I come back to VPN and find this conversation, so all my problems were resolved by un-checking "Disconnect when computer goes to sleep" in the "Advanced" settings window as recommended by the Tunnelblick developer.

So now everything works as a charm, no hanging up or freezing after MacBook wake up, reconnection happens almost instantly and Firefox doesn't crush, no interruption in my working environment with errors 403 or 500 and no need to kill Firefox or wait.

[Chris Wilson]

Hi all,

I'm having the same problem as Marc Günther, that Tunnelblick reproducibly locks up when switching user. Like Testy Tester, my second user doesn't have Tunnelblick configured at all. It doesn't happen when I suspend the laptop.

Would you like me to test any different versions, or send a spindump (and if so, how)?

Thanks, Chris.

[Testy Tester]

Chris, in https://groups.google.com/g/tunnelblick-discuss/c/lU294x7afYI/m/s3gHH4iJAQAJ I show a small script that is a useful and quick workaround for this problem. Does it help you?

[Testy Tester]

This has finally been fixed in 4.0.0b8. Thank you.

[Daniel Schulz]

Hi all,

unfortunately, this issue, or at least a similar one, still occurs on my machine.

My setup

• MacBook Pro 2019
  • Processor 2,4 GHz 8-Core Intel Core i9
  • macos: 14.4.1 (23E224)
  • Tunnelblick 4.0.1 (build 5971) 
    

Steps to reproduce:

1. Open Tunnelblick
2. Connect to a server
3. Bring the Macbook to sleep / close the lid
4. Make the wifi connection unavailable
5. Bring the Macbook up / open the lid
6. Now the Tunnelblick process is hanging / the menu bar item UI will be unresponsive 

Please let me know if I can help you with further details.

Thanks, Daniel.

[Tunnelblick developer]

Daniel, please post the diagnostic info obtained by following the instructions at Read Before You Post.

[Daniel Schulz]

Thank you for getting back to me.

As I previously noted, the Tunnelblick application either crashes/hangs completely, preventing me from accessing the user interface to use the "Copy Diagnostic Info to the Clipboard" button. From what I recall, the connection logs were either empty or contained only minimal information. 

I will double-check this as soon as I have the opportunity and come back with further information.

Best,

Daniel

[Tunnelblick developer]

Daniel, I apologize for not being more clear: please post the diagnostic info from a connect/disconnect without sleeping.