Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Arch Linux issue #611

Closed
DL6ER opened this issue Jul 8, 2019 · 5 comments
Closed

Arch Linux issue #611

DL6ER opened this issue Jul 8, 2019 · 5 comments
Labels
Duplicate External issue

Comments

@DL6ER
Copy link
Member

DL6ER commented Jul 8, 2019

/dev/shm in a kvm vm hosted on Proxmox aint the problem.
Squid, wich is using /dev/shm, isnt crashing in the same vm.

ls -l /dev/shm | awk '{print $1, $9}'

-rw------- FTL-clients
-rw------- FTL-counters
-rw------- FTL-domains
-rw------- FTL-forwarded
-rw------- FTL-lock
-rw------- FTL-overTime
-rw------- FTL-queries
-rw------- FTL-settings
-rw------- FTL-strings
-rw------- c-icap-shared-kids-queue.1
-rw------- squid-cache_mem_ex.shm
-rw------- squid-cache_mem_map_anchors.shm
-rw------- squid-cache_mem_map_filenos.shm
-rw------- squid-cache_mem_map_slices.shm
-rw------- squid-cache_mem_space.shm
-rw------- squid-cf__metadata.shm
-rw------- squid-cf__queues.shm
-rw------- squid-cf__readers.shm
-rw------- squid-io_file__metadata.shm
-rw------- squid-io_file__queues.shm
-rw------- squid-io_file__readers.shm
-rw------- squid-squid-page-pool.shm
-rw------- squid-tls_session_cache.shm
-rw------- squid-var.spool.squid.rock_map_anchors.shm
-rw------- squid-var.spool.squid.rock_map_filenos.shm
-rw------- squid-var.spool.squid.rock_map_slices.shm
-rw------- squid-var.spool.squid.rock_spaces.shm

Im running Arch linux.

cat /etc/lsb-release 
LSB_VERSION=1.4
DISTRIB_ID=Arch
DISTRIB_RELEASE=rolling
DISTRIB_DESCRIPTION="Arch Linux"

After upgrading nettle to version 3.5.1-1 i had to recompile pi-hole-ftl, than the service started crasching randomly. Here is a trace from systemd-coredump:

systemd-coredump[28316]: Process 28305 (pihole-FTL) of user 0 dumped core.
                                               
                                               Stack trace of thread 28305:
                                               #0  0x00007fab74436755 raise (libc.so.6)
                                               #1  0x00007fab74421851 abort (libc.so.6)
                                               #2  0x0000562a15c43958 n/a (pihole-FTL)
                                               #3  0x00007fab745d2d00 __restore_rt (libpthread.so.0)
                                               #4  0x00007fab7463e826 __gmpz_roinit_n (libgmp.so.10)
                                               #5  0x00007fab745f5592 nettle_ecc_point_set (libhogweed.so.5)
                                               #6  0x0000562a15c95e96 n/a (pihole-FTL)
                                               #7  0x0000562a15c83e40 n/a (pihole-FTL)
                                               #8  0x0000562a15c8657a dnssec_validate_by_ds (pihole-FTL)
                                               #9  0x0000562a15c62a3a reply_query (pihole-FTL)
                                               #10 0x0000562a15c7346c n/a (pihole-FTL)
                                               #11 0x0000562a15c74e9a main_dnsmasq (pihole-FTL)
                                               #12 0x0000562a15c41f86 main (pihole-FTL)
                                               #13 0x00007fab74422ee3 __libc_start_main (libc.so.6)
                                               #14 0x0000562a15c420be _start (pihole-FTL)
                                               
                                               Stack trace of thread 28306:
                                               #0  0x00007fab745d1b9f accept (libpthread.so.0)
                                               #1  0x0000562a15c43e4b n/a (pihole-FTL)
                                               #2  0x0000562a15c441e6 telnet_listening_thread_IPv4 (pihole-FTL)
                                               #3  0x00007fab745c857f start_thread (libpthread.so.0)
                                               #4  0x00007fab744f80e3 __clone (libc.so.6)
                                               
                                               Stack trace of thread 28307:
                                               #0  0x00007fab745d1b9f accept (libpthread.so.0)
                                               #1  0x0000562a15c43e4b n/a (pihole-FTL)
                                               #2  0x0000562a15c44336 telnet_listening_thread_IPv6 (pihole-FTL)
                                               #3  0x00007fab745c857f start_thread (libpthread.so.0)
                                               #4  0x00007fab744f80e3 __clone (libc.so.6)
                                               
                                               Stack trace of thread 28308:
                                               #0  0x00007fab745d1b9f accept (libpthread.so.0)
                                               #1  0x0000562a15c43eb7 n/a (pihole-FTL)
                                               #2  0x0000562a15c4447f socket_listening_thread (pihole-FTL)
                                               #3  0x00007fab745c857f start_thread (libpthread.so.0)
                                               #4  0x00007fab744f80e3 __clone (libc.so.6)
                                               
                                               Stack trace of thread 28310:
                                               #0  0x00007fab744efe5b __select (libc.so.6)
                                               #1  0x0000562a15c42e39 sleepms (pihole-FTL)
                                               #2  0x0000562a15c4fcf5 DNSclient_thread (pihole-FTL)
                                               #3  0x00007fab745c857f start_thread (libpthread.so.0)
                                               #4  0x00007fab744f80e3 __clone (libc.so.6)
                                               
                                               Stack trace of thread 28309:
                                               #0  0x00007fab744efe5b __select (libc.so.6)
                                               #1  0x0000562a15c42e39 sleepms (pihole-FTL)
                                               #2  0x0000562a15c462fa GC_thread (pihole-FTL)
                                               #3  0x00007fab745c857f start_thread (libpthread.so.0)
                                               #4  0x00007fab744f80e3 __clone (libc.so.6)

libhogweed.so.5 comes from nettle

pkgfile libhogweed.so.5 
core/nettle

pihole-FTL.services is crashing frequently.

journalctl -u pihole-FTL.service --since "1 days ago" > pihole-FTL_service.log

pihole-FTL_service.log

Originally posted by @gituriu1 in #606 (comment)
@DL6ER
Copy link
Member Author

DL6ER commented Jul 8, 2019

@dschaper wrote:

https://aur.archlinux.org/packages/pi-hole-ftl/#pinned-633054
https://aur.archlinux.org/packages/pi-hole-ftl/#comment-699671
And your permissions on the /dev/shm files (600) are problematic.

See the pinned post in the AUR.

@gituriu1 wrote:

so i downgraded nettle to 3.4 3.4-1 (libhogweed.so.4) and recompiled pihole by editing the PKGBUILD and fixing the dependendy for nettle, but still > pi-hole-ftl 4.3.1-2 crashes:

systemd-coredump[11155]: Process 11129 (pihole-FTL) of user 0 dumped core.

                                               Stack trace of thread 11129:
                                               #0  0x00007f7f092e5755 raise (libc.so.6)
                                               #1  0x00007f7f092d0851 abort (libc.so.6)
                                               #2  0x000055b13b06a958 n/a (pihole-FTL)
                                               #3  0x00007f7f09481d00 __restore_rt (libpthread.so.0)
                                               #4  0x00007f7f096ea826 __gmpz_roinit_n (libgmp.so.10)
                                               #5  0x00007f7f094a28b6 nettle_ecc_point_set (libhogweed.so.4)
                                               #6  0x000055b13b0bce96 n/a (pihole-FTL)
                                               #7  0x000055b13b0aae40 n/a (pihole-FTL)
                                               #8  0x000055b13b0ad57a dnssec_validate_by_ds (pihole-FTL)
                                               #9  0x000055b13b089a3a reply_query (pihole-FTL)
                                               #10 0x000055b13b09a46c n/a (pihole-FTL)
                                               #11 0x000055b13b09be9a main_dnsmasq (pihole-FTL)
                                               #12 0x000055b13b068f86 main (pihole-FTL)
                                               #13 0x00007f7f092d1ee3 __libc_start_main (libc.so.6)
                                               #14 0x000055b13b0690be _start (pihole-FTL)
                                               
                                               Stack trace of thread 11131:
                                               #0  0x00007f7f09480b9f accept (libpthread.so.0)
                                               #1  0x000055b13b06ae4b n/a (pihole-FTL)
                                               #2  0x000055b13b06b336 telnet_listening_thread_IPv6 (pihole-FTL)
                                               #3  0x00007f7f0947757f start_thread (libpthread.so.0)
                                               #4  0x00007f7f093a70e3 __clone (libc.so.6)
                                               
                                               Stack trace of thread 11130:
                                               #0  0x00007f7f09480b9f accept (libpthread.so.0)
                                               #1  0x000055b13b06ae4b n/a (pihole-FTL)
                                               #2  0x000055b13b06b1e6 telnet_listening_thread_IPv4 (pihole-FTL)
                                               #3  0x00007f7f0947757f start_thread (libpthread.so.0)
                                               #4  0x00007f7f093a70e3 __clone (libc.so.6)
                                               
                                               Stack trace of thread 11132:
                                               #0  0x00007f7f09480b9f accept (libpthread.so.0)
                                               #1  0x000055b13b06aeb7 n/a (pihole-FTL)
                                               #2  0x000055b13b06b47f socket_listening_thread (pihole-FTL)
                                                                  
                                               Stack trace of thread 11133:
                                               #0  0x00007f7f0939ee5b __select (libc.so.6)
                                               #1  0x000055b13b069e39 sleepms (pihole-FTL)
                                               #2  0x000055b13b06d2fa GC_thread (pihole-FTL)
                                               #3  0x00007f7f0947757f start_thread (libpthread.so.0)
                                               #4  0x00007f7f093a70e3 __clone (libc.so.6)
                                               
                                               Stack trace of thread 11134:
                                               #0  0x00007f7f0939ee5b __select (libc.so.6)
                                               #1  0x000055b13b069e39 sleepms (pihole-FTL)
                                               #2  0x000055b13b076cf5 DNSclient_thread (pihole-FTL)
                                               #3  0x00007f7f0947757f start_thread (libpthread.so.0)
                                               #4  0x00007f7f093a70e3 __clone (libc.so.6)

@DL6ER wrote:

Concerning the does-not-work-with-libnettle-3.5 you should have looked into our open issue tickets: #603

This bug is a dnsmasq regression. We will adopt the fix from dnsmasq upstream as soon as it is implemented (we will not wait until dnsmasq v2.81 is released). Doing it this way avoids merge conflicts caused by us doing it maybe in a different way than Simon will do it.

It is worth pointing out that I linked a patch for using pihole-FTL + libnettle3.5 in the mentioned issue ticket, however, as the precompiled binaries we provide for Pi-hole's are compiled against the last working version of the library and our "compile from source" instructions specifically asks users to use said version (3.4), this is a low priority bug that does not justify merge conflicts with dnsmasq upstream.

In fact, Arch is probably the only affected distribution as everything else uses our precompiled binaries which do not crash.

@DL6ER
Copy link
Member Author

DL6ER commented Jul 8, 2019

so i downgraded nettle to 3.4 3.4-1 (libhogweed.so.4) and recompiled pihole by editing the PKGBUILD and fixing the dependendy for nettle, but still > pi-hole-ftl 4.3.1-2 crashes

I suppose you're still compiling against libnettle3.5. Make sure you purged the entire library and run make clean in your FTL repository before trying again to compile. If nothing helps and you cannot get rid of libnettle 3.5, you may as well apply the patch I linked in #603

@leogx9r
Copy link

leogx9r commented Jul 8, 2019

@DL6ER I already posted a fix in the AUR comments just a few minutes ago. Like someone pointed out, it's due to missing symbols dnsmasq references in nettle.

diff -Nurp a/dnsmasq/crypto.c b/dnsmasq/crypto.c
--- a/dnsmasq/crypto.c  2019-07-08 10:09:06.000000000 +0000
+++ b/dnsmasq/crypto.c  2019-07-08 10:12:32.000000000 +0000
@@ -275,6 +275,10 @@ static int dnsmasq_ecdsa_verify(struct b
   static struct ecc_point *key_256 = NULL, *key_384 = NULL;
   static mpz_t x, y;
   static struct dsa_signature *sig_struct;
+  #if NETTLE_VERSION_MAJOR == 3 && NETTLE_VERSION_MINOR < 4
+    #define nettle_get_secp_256r1() (&nettle_secp_256r1)
+    #define nettle_get_secp_384r1() (&nettle_secp_384r1)
+  #endif

   if (!sig_struct)
     {
@@ -294,7 +298,7 @@ static int dnsmasq_ecdsa_verify(struct b
      if (!(key_256 = whine_malloc(sizeof(struct ecc_point))))
        return 0;

-     nettle_ecc_point_init(key_256, &nettle_get_secp_256r1);
+     nettle_ecc_point_init(key_256, nettle_get_secp_256r1());
    }

       key = key_256;
@@ -307,7 +311,7 @@ static int dnsmasq_ecdsa_verify(struct b
      if (!(key_384 = whine_malloc(sizeof(struct ecc_point))))
        return 0;

-     nettle_ecc_point_init(key_384, &nettle_get_secp_384r1);
+     nettle_ecc_point_init(key_384, nettle_get_secp_384r1());
    }

       key = key_384;

Recompile with the above patch and it should solve the issue for you.

@DL6ER
Copy link
Member Author

DL6ER commented Jul 9, 2019

I'll close this issue as a patch has been proposed which is identical with the patch suggested in #603.
Compatibility with libnettle3.5 will be further tracked in #603.

Closing this as turned out to be a duplicate.

@DL6ER DL6ER closed this as completed Jul 9, 2019
@DL6ER DL6ER added the Duplicate label Jul 9, 2019
@gituriu1
Copy link

gituriu1 commented Jul 9, 2019

sorry for hijacking, thx for linking to the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Duplicate External issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@DL6ER @leogx9r @gituriu1