clightning uses all my resources, ... till I have to shutdown! clightning runs for a while great. However, every second day the computer locks up, 

I use docker-compose for that:

version: "3"
services:
  bitcoind:
    image: nicolasdorier/docker-bitcoin:0.16.3
    container_name: bitcoind
    environment:
      BITCOIN_EXTRA_ARGS: |
        testnet=0
        whitelist=0.0.0.0/0
        server=1
        rpcuser=*****
        rpcpassword=*****
    expose:
      - "8333"
    ports:
      - "0.0.0.0:8333:8333"
    volumes:
      - "/media/ronald/data/scratch/bitcoin/mainnet/bitcoind:/data"

  clightning_bitcoin:
    image: elementsproject/lightningd
    container_name: lightning
    command:
      - --bitcoin-rpcconnect=bitcoind
      - --bitcoin-rpcuser=****
      - --bitcoin-rpcpassword=****
      - --network=bitcoin
      - --alias=TWronald✅
      - --rgb=15C315
      - --log-level=debug
      - --announce-addr=220.133.223.206:9735
      - --bind-addr=0.0.0.0:9735
    environment:
      EXPOSE_TCP: "true"
    expose:
      - "9735"
    ports:
      - "0.0.0.0:9735:9735"
    volumes:
      - "/media/ronald/data/scratch/bitcoin/mainnet/clightning:/root/.lightning"
      - "/media/ronald/data/scratch/bitcoin/mainnet/bitcoind:/etc/bitcoin"
    links:
      - bitcoind


lightning-cli getinfo

{
  "id": "035aef5661e1a6e370db60dc0455796800afd5b51fbc12a0a8b34836b15f5d7ef6", 
  "alias": "TWronald✅", 
  "color": "15c315", 
  "num_peers": 15, 
  "num_pending_channels": 0, 
  "num_active_channels": 15, 
  "num_inactive_channels": 0, 
  "address": [
    {
      "type": "ipv4", 
      "address": "220.133.223.206", 
      "port": 9735
    }
  ], 
  "binding": [
    {
      "type": "ipv4", 
      "address": "0.0.0.0", 
      "port": 9735
    }
  ], 
  "version": "", 
  "blockheight": 560987, 
  "network": "bitcoin", 
  "msatoshi_fees_collected": 0
}


Why the version of lightning is "" ??? scratch/bitcoin/mainet/clightning/config is empty.

Currently it is running fine. 
ps ax |grep lightn

 7278 ?        S      0:03 /usr/bin/lightning_channeld
 8524 pts/20   S+     0:00 grep --color=auto lightn
16579 ?        S      0:06 /usr/bin/lightning_channeld
31660 ?        S      1:19 lightningd --bitcoin-rpcconnect=bitcoind --bitcoin-rpcuser=**** --bitcoin-rpcpassword=**** --network=bitcoin --alias=TWronald✅ --rgb=15C315 --log-level=debug --announce-addr=220.133.223.206:9735 --bind-addr=0.0.0.0:9735
31665 ?        Z      0:00 [lightning_chann] &lt;defunct&gt;
31666 ?        Z      0:00 [lightning_closi] &lt;defunct&gt;
31667 ?        Z      0:00 [lightning_conne] &lt;defunct&gt;
31668 ?        Z      0:00 [lightning_gossi] &lt;defunct&gt;
31669 ?        Z      0:00 [lightning_hsmd] &lt;defunct&gt;
31670 ?        Z      0:00 [lightning_oncha] &lt;defunct&gt;
31671 ?        Z      0:00 [lightning_openi] &lt;defunct&gt;
31675 ?        S      0:00 /usr/bin/lightning_hsmd
31677 ?        S      0:00 /usr/bin/lightning_connectd
31678 ?        S      5:45 /usr/bin/lightning_gossipd
31862 ?        S      0:00 socat TCP4-listen:9835,fork,reuseaddr UNIX-CONNECT:/root/.lightning/lightning-rpc
31868 ?        S      0:06 /usr/bin/lightning_channeld
31869 ?        S      0:09 /usr/bin/lightning_channeld
31870 ?        S      0:06 /usr/bin/lightning_channeld
31871 ?        S      0:07 /usr/bin/lightning_channeld
31872 ?        S      0:07 /usr/bin/lightning_channeld
31874 ?        S      0:10 /usr/bin/lightning_channeld
31875 ?        S      0:10 /usr/bin/lightning_channeld
31876 ?        S      0:06 /usr/bin/lightning_channeld
31879 ?        S      0:10 /usr/bin/lightning_channeld
31988 ?        S      0:06 /usr/bin/lightning_channeld
31989 ?        S      0:06 /usr/bin/lightning_channeld
31992 ?        S      0:07 /usr/bin/lightning_channeld


... but still some Zombies.

When it grinds to a hold, it uses most with gossip.

Can you spot some changes I should make to improve my system?
This is most likely the gossipd bug that was causing a request from a peer to be processed very slowly. It was fixed in PR 2268. You don't have that fix in your installation yet, which can be seen by the 5 daemons that are not being reaped correctly (the &lt;defunct&gt; processes in the list). This was also fixed in PR 2224.

Both fixes are not yet part of a release, but we will release them soon.