bitcoin-qt (and possibly bitcoind) shutdown delay on debian stretch #9398

issue possientis openend this issue on December 21, 2016
  1. possientis commented at 6:46 am on December 21, 2016: none

    bitcoin-qt shutdown systematically takes about 5 minutes on my new debian stretch system. A typical debug file looks as follows:

    2016-12-20 19:58:55 AcceptToMemoryPool: peer=3: accepted 2b8c3...5c14 (poolsz ...
    2016-12-20 19:58:56 AcceptToMemoryPool: peer=3: accepted 4a3d1...7e0e (poolsz ...
    2016-12-20 19:58:56 tor: Thread interrupt
    2016-12-20 19:58:56 scheduler thread interrupt
    2016-12-20 19:58:56 torcontrol thread exit
    2016-12-20 19:58:56 opencon thread interrupt
    2016-12-20 19:58:56 addcon thread interrupt
    2016-12-20 19:58:56 msghand thread interrupt
    2016-12-20 19:58:56 net thread interrupt
    

    This is where it hangs for a few minutes, then:

    2016-12-20 20:05:58 Imported mempool transactions from disk: 10932 successes, 476 failed, 0 expired
    2016-12-20 20:05:58 Shutdown: In progress...
    2016-12-20 20:05:58 Stop
    2016-12-20 20:05:59 Erased 1 orphan tx from peer 5 
    2016-12-20 20:06:01 Dumped mempool: 0.063746s to copy, 1.55051s to dump
    2016-12-20 20:06:01 Shutdown: done
    

    I have never experienced this behavior before. However, I am dealing with a pre-release test build (v0.13.99.0-8c7947e) on a new version of debian (stretch) on new hardware which is very cheap and very slow. (EDIT: I initially thought this behavior was specific to bitcoin-qt and that bitcoind would shutdown immediately, but I have just had a case of bitcoind taking 5 minutes to shutdown.)

    $ uname -a 
    Linux front 4.8.0-1-amd64 [#1](/bitcoin-bitcoin/1/) SMP Debian 4.8.7-1 (2016-11-13) x86_64 GNU/Linux
    
    $ lscpu
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                2
    On-line CPU(s) list:   0,1
    Thread(s) per core:    1
    Core(s) per socket:    2
    Socket(s):             1
    NUMA node(s):          1
    Vendor ID:             GenuineIntel
    CPU family:            6
    Model:                 76
    Model name:            Intel(R) Celeron(R) CPU  N3050  @ 1.60GHz
    Stepping:              3
    CPU MHz:               479.980
    CPU max MHz:           2160.0000
    CPU min MHz:           480.0000
    BogoMIPS:              3200.00
    Virtualization:        VT-x
    L1d cache:             24K
    L1i cache:             32K
    L2 cache:              1024K
    NUMA node0 CPU(s):     0,1
    Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
    clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon 
    pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
    ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes
    rdrand lahf_lm 3dnowprefetch epb tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms
    dtherm ida arat
    
    $ df -h
    Filesystem                  Size  Used Avail Use% Mounted on
    udev                        3.9G     0  3.9G   0% /dev
    tmpfs                       790M   18M  772M   3% /run
    /dev/mapper/front--vg-root   23G  8.5G   14G  40% /
    tmpfs                       3.9G  428K  3.9G   1% /dev/shm
    tmpfs                       5.0M     0  5.0M   0% /run/lock
    tmpfs                       3.9G     0  3.9G   0% /sys/fs/cgroup
    /dev/mapper/front--vg-var   9.2G  2.2G  6.5G  26% /var
    /dev/mapper/front--vg-tmp   1.8G  8.0M  1.7G   1% /tmp
    /dev/sda2                   237M   38M  187M  17% /boot
    /dev/sda1                   511M  132K  511M   1% /boot/efi
    /dev/mapper/front--vg-home  874G  131G  699G  16% /home
    tmpfs                       790M   16K  790M   1% /run/user/117
    tmpfs                       790M   24K  790M   1% /run/user/1000
    
    $ free
                  total        used        free      shared  buff/cache   available
    Mem:        8083768     1237252     2104880      267092     4741636     6273948
    Swap:       8290300           0     8290300
    
  2. possientis renamed this:
    bitcoin-qt shutdown delay on debian stretch [wallet]
    bitcoin-qt shutdown delay on debian stretch
    on Dec 21, 2016
  3. possientis renamed this:
    bitcoin-qt shutdown delay on debian stretch
    bitcoin-qt (and possibly bitcoind) shutdown delay on debian stretch
    on Dec 21, 2016
  4. paveljanik commented at 7:20 am on December 21, 2016: contributor
    02016-12-20 20:05:58 Imported mempool transactions from disk: 10932 successes, 476 failed, 0 expired
    

    This looks like you have not even finished loading mempool.dat. Tried the same here, same result. @sipa Please have a look.

  5. laanwj added the label Mempool on Dec 21, 2016
  6. MarcoFalke added the label Resource usage on Dec 21, 2016
  7. instagibbs commented at 3:23 pm on December 21, 2016: member

    Having same issue on Ubuntu 16.04

    2016-12-21 15:14:41 tor: Thread interrupt 2016-12-21 15:14:41 torcontrol thread exit 2016-12-21 15:14:41 addcon thread interrupt 2016-12-21 15:14:41 opencon thread interrupt 2016-12-21 15:14:41 scheduler thread interrupt 2016-12-21 15:14:41 net thread interrupt 2016-12-21 15:14:42 msghand thread interrupt 2016-12-21 15:19:08 Imported mempool transactions from disk: 7213 successes, 121 failed, 0 expired 2016-12-21 15:19:08 Shutdown: In progress… 2016-12-21 15:19:08 Stop 2016-12-21 15:19:09 Dumped mempool: 0.022091s to copy, 0.281887s to dump 2016-12-21 15:19:10 Shutdown: done

    Not sure if coincidence, but I was also syncing blocks very slowly on mainnet. I did a make clean and both issues are gone.

  8. jonasschnelli commented at 8:14 am on December 22, 2016: contributor
    The reason for this is, that LoadMempool() can take a while and there is no abort logic when a shutdown was triggered. Also, if we do this, we need to be careful to not dump the mempool during the shutdown process in case we have aborted an import.
  9. paveljanik commented at 6:25 pm on January 8, 2017: contributor
    @possientis Should be fixed by #9408. Can you confirm?
  10. possientis commented at 10:15 pm on January 8, 2017: none
    building master branch commit 25720fc394e27a951bcad26095fb5a711bfacb8f . Will revert asap. Incidentally, for some reason, I have not yet witnessed the issue on v0.13.2
  11. possientis commented at 11:51 pm on January 8, 2017: none
    All good for me, build and tests successful, no delay on shutdown for either bitcoin-qt or bitcoind
  12. paveljanik commented at 5:38 am on January 9, 2017: contributor
    @possientis Thanks for testing, this can be Closed now then.
  13. fanquake commented at 6:43 am on January 9, 2017: member
    Closing as fixed by #9408
  14. fanquake closed this on Jan 9, 2017

  15. MarcoFalke locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-17 15:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me