Arch Linux User Repository

Please note the following requirements for AWS VPN Client:

• If you depend on DNS servers from VPN you need to have a running systemd-resolved.service. Please ensure it does not conflict with any other DNS resolver service or configuration you may use. sudo systemctl --now enable systemd-resolved.service

• You have to enable and start the awsvpnclient.service after installation: sudo systemctl --now enable awsvpnclient

For troubelshooting its worth checking first the logs:

/home/$USER/.config/AWSVPNClient/
/var/log/aws-vpn-client/$USER/

See also the official docs: https://docs.aws.amazon.com/vpn/latest/clientvpn-user/client-vpn-connect-linux.html

If you face any other problem please check the troubleshooting guide (DNS issues): https://docs.aws.amazon.com/vpn/latest/clientvpn-user/linux-troubleshooting.html#aws-provided-client

@project0, I get the same thing with 1.0.3. The strace output doesn't make it clear what the real problem is (unless someone else here is good at reading and dissecting them).

For now I locked this package to 1.0.2 on my end. Hopefully AWS fixes this in their next version.

Is 1.0.3 working for someone on arch? I get segfaults starting the UI, but i am not sure if its a problem at my side. The daemon seems good to me, but the UI does not start.

I tested the client vpn in a ubuntu VM as well and its working fine, so i believe there is some incompatibility with Arch Linux.

stat("/opt/awsvpnclient/System.Diagnostics.Process.dll", {st_mode=S_IFREG|0764, st_size=229248, ...}) = 0
openat(AT_FDCWD, "/opt/awsvpnclient/System.Diagnostics.Process.dll", O_RDONLY) = 105
fcntl(105, F_SETFD, FD_CLOEXEC)         = 0
fstat(105, {st_mode=S_IFREG|0764, st_size=229248, ...}) = 0
fcntl(105, F_DUPFD_CLOEXEC, 0)          = 106
fstat(106, {st_mode=S_IFREG|0764, st_size=229248, ...}) = 0
mmap(NULL, 229248, PROT_READ, MAP_SHARED, 106, 0) = 0x7f23cc2c8000
munmap(0x7f23cc2c8000, 229248)          = 0
close(106)                              = 0
pread64(105, "MZ\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 64, 0) = 64
pread64(105, "PE\0\0\35\375\3\0\3%\302\304\0\0\0\0\0\0\0\0\360\0\" \v\2\v\0\0\0\0\0"..., 264, 128) = 264
mmap(0x7f23f9f10000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED, 105, 0) = 0x7f23f9f10000
mmap(0x7f23f9f20000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 105, 0) = 0x7f23f9f20000
mmap(0x7f23f9f32000, 210432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 105, 0x2000) = 0x7f23f9f32000
mmap(0x7f23f9f75000, 3072, PROT_READ, MAP_PRIVATE|MAP_FIXED, 105, 0x35000) = 0x7f23f9f75000
mprotect(0x7f23f9f05000, 8192, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9f07000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9f08000, 8192, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9f0a000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9efb000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9efc000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9efd000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9da1000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9da1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
getpid()                                = 7861
mprotect(0x7f23f9da2000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9da2000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x7f23f9f0b000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9da3000, 8192, PROT_READ|PROT_WRITE) = 0
mprotect(0x7f23f9da3000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x7f23f9efe000, 4096, PROT_READ|PROT_WRITE) = 0
getpid()                                = 7861
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
rt_sigprocmask(SIG_UNBLOCK, [RT_2], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RT_2], NULL, 8) = 0
rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f2471a3a870}, NULL, 8) = 0
unlink("/tmp/clr-debug-pipe-7861-235228-in") = 0
unlink("/tmp/clr-debug-pipe-7861-235228-out") = 0
unlink("/tmp/dotnet-diagnostic-7861-235228-socket") = 0
rt_sigreturn({mask=[]})                 = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++
[1]    7858 segmentation fault (core dumped)  strace /opt/awsvpnclient/AWS\ VPN\ Client

1.0.3 is dying with

2021-11-11 18:28:37.222 +01:00 [DBG] /bin/ps exit code: 1
2021-11-11 18:28:37.223 +01:00 [ERR] [TI=20] Failed to get process owner of PID: 119146. Stdout: , stderr: 
2021-11-11 18:28:37.249 +01:00 [WRN] [TI=20] Exception occured checking process alive: System.Exception: Failed to get process owner of PID: 119146
   at ACVC.GTK.Service.DBus.OvpnGtkService.GetProcessOwner(Int32 pid) in /home/ubuntu/Jenkins/workspace/GtkBuild/SecureConnectClient/ACVC.GTK.Service/DBus/OvpnGtkService.cs:line 276
   at ACVC.GTK.Service.DBus.OvpnGtkService.IsAliveAsync(Int32 pid) in /home/ubuntu/Jenkins/workspace/GtkBuild/SecureConnectClient/ACVC.GTK.Service/DBus/OvpnGtkService.cs:line 185

Thanks for quick release!

I believe that the current source definition might be problematic due to AWS not naming the .deb differently with each release. Because of that, if any user that decides against performing a clean build for the package tries to update, will most likely use already existing .deb in their cache directory (and fail on checksum checks).

Maybe this PKGBUILD could use the double colon syntax to rename the source package to avoid invalid caches?

@damentz your fix worked for me. Great job!

EDIT: Ok I figured out how to fix it, just chmod 000 ~/.config/AWSVPNClient/awsvpnclientmetrics.db. Running a strace shows that it can't access the file and it proceeds to start up.

ORIGINAL POST:

I just got the same issue today, it looks like something to do with the awsvpnclientmetrics.db file, according to a strace:

newfstatat(AT_FDCWD, "/home/<my user>/.config/AWSVPNClient/awsvpnclientmetrics.db", 0x7ffde38dc6c0, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
getpid()                                = 5027
getpid()                                = 5027
openat(AT_FDCWD, "/home/<my user>/.config/AWSVPNClient/awsvpnclientmetrics.db", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 103
newfstatat(103, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0
newfstatat(103, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0
newfstatat(AT_FDCWD, "/home/<my user>/.config/AWSVPNClient/awsvpnclientmetrics.db", {st_mode=S_IFREG|0644, st_size=0, ...}, 0) = 0
pread64(103, "", 100, 0)                = 0
brk(0x24e0000)                          = 0x24e0000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x188070e8} ---
rt_sigprocmask(SIG_UNBLOCK, [RT_2], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RT_2], NULL, 8) = 0
rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7ff94ae1c870}, NULL, 8) = 0
unlink("/tmp/clr-debug-pipe-5027-81603-in") = 0
unlink("/tmp/clr-debug-pipe-5027-81603-out") = 0
unlink("/tmp/dotnet-diagnostic-5027-81603-socket") = 0
rt_sigreturn({mask=[]})                 = 411070688
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x188070e8} ---
+++ killed by SIGSEGV (core dumped) +++

@jantman, I double checked a few ways and the AWS VPN Client isn't running on my system prior to running it. Are you killing the service instead?

@K5HV I had a similar issue with the client segfaulting. I can't believe I'm actually saying this, but is there a chance that you have another instance of the client (the GUI part, "AWS VPN Client") running?

After the latest update, I tried to start the client and apparently it ended up behind another window, and didn't have a taskbar entry. I tried to start the client again, and kept getting segmentation faults, over and over. Eventually I looked in the process list, found out that "AWS VPN Client" was already running, killed that process, and then it worked fine.

Does anybody has a problem with client? It was working few days ago and stopped recently:

k5hv:~/ $ /opt/awsvpnclient/AWS\ VPN\ Client                                                                                                                                                                                       
[1]    9122 segmentation fault (core dumped)  /opt/awsvpnclient/AWS\ VPN\ Client

dmesg:

[ 1544.910131] AWS VPN Client[9122]: segfault at 6275598 ip 00007f60efc962d6 sp 00007fffcdeab678 error 4 in SQLite.Interop.dll[7f60efc77000+17e000]
[ 1544.910150] Code: 45 d8 8b 08 89 d0 ba 00 00 00 00 f7 f1 89 55 ec 48 8b 45 d8 48 8b 40 10 8b 55 ec 48 c1 e2 04 48 01 d0 48 89 45 f8 48 8b 45 f8 <48> 8b 40 08 48 89 45 f0 48 8b 45 f8 8b 00 89 45 e8 eb 1d c7 45 ec

@project0, the command regarding systemd-resolved in the pinned command is missing systemctl. Instead of sudo enable systemd-resolved.service && sudo start systemd-resolved.service, it should be sudo systemctl enable systemd-resolved.service && sudo systemctl start systemd-resolved.service