Debugging systemd para o mongodb 3.2 no Ubuntu 16.04 - sig 15 killing

2

Instalei o mongodb-org e o mongodb-org-server seguindo as instruções no mongodb.org (embora para o Ubuntu 14.x)

Neste ponto, o mongodb em execução funciona diretamente;

sudo -H -u mongodb bash -c "/usr/bin/mongod -f /etc/mongod.conf"

em /var/log/mongodb.log

2016-06-15T00:57:10.718Z I NETWORK  [initandlisten] waiting for connections on port 27017

Eu criei um /lib/systemd/system/mongodb.service (semelhante ao link )

[Unit]
Description=High-performance, schema-free document-oriented database
After=syslog.target network.target

[Service]
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod -f /etc/mongod.conf
ExecStop=/usr/bin/mongod -f /etc/mongod.conf --shutdown

[Install]
WantedBy=multi-user.target

No mongodb.log este é o resultado;

2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] MongoDB starting : pid=5592 port=27017 dbpath=/data/wiredtiger 64-bit host=neptune
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] db version v3.2.7
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] git version: 4249c1d2b5999ebbf1fdf3bc0e0e3b3ff5c0aaf2
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2g-fips  1 Mar 2016
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] allocator: tcmalloc
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] modules: none
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] build environment:
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten]     distmod: ubuntu1404
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten]     distarch: x86_64
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten]     target_arch: x86_64
2016-06-15T00:47:53.748Z I CONTROL  [initandlisten] options: { config: "/etc/mongod.conf", net: { bindIp: "127.0.0.1", port: 27017, unixDomainSocket: { enabled: true, filePermissions: 329, pathPrefix: "/data/wiredtiger" } }, processManagement: { fork: true, pidFilePath: "/var/run/mongodb/mongodb.pid" }, setParameter: { failIndexKeyTooLong: "false" }, storage: { dbPath: "/data/wiredtiger", directoryPerDB: true, engine: "wiredTiger", journal: { enabled: true }, wiredTiger: { collectionConfig: { blockCompressor: "snappy" }, engineConfig: { cacheSizeGB: 1, directoryForIndexes: true } } }, systemLog: { destination: "file", logAppend: true, path: "/var/log/mongodb/mongodb.log", timeStampFormat: "iso8601-utc" } }
2016-06-15T00:47:53.770Z I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=1G,session_max=20000,eviction=(threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] 
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] 
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2016-06-15T00:47:54.257Z I CONTROL  [initandlisten] 
2016-06-15T00:47:54.270Z I FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '/data/wiredtiger/diagnostic.data'
2016-06-15T00:47:54.271Z I NETWORK  [HostnameCanonicalizationWorker] Starting hostname canonicalization worker
2016-06-15T00:47:54.271Z I NETWORK  [initandlisten] waiting for connections on port 27017
2016-06-15T00:47:54.305Z I CONTROL  [main] ***** SERVER RESTARTED *****
2016-06-15T00:47:54.310Z I CONTROL  [signalProcessingThread] got signal 15 (Terminated), will terminate after current cmd ends
2016-06-15T00:47:54.310Z I FTDC     [signalProcessingThread] Shutting down full-time diagnostic data capture
2016-06-15T00:47:54.310Z I CONTROL  [signalProcessingThread] now exiting
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] shutdown: going to close listening sockets...
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] closing listening socket: 6
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] closing listening socket: 7
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] removing socket file: /data/wiredtiger/mongodb-27017.sock
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] shutdown: going to flush diaglog...
2016-06-15T00:47:54.310Z I NETWORK  [signalProcessingThread] shutdown: going to close sockets...
2016-06-15T00:47:54.310Z I STORAGE  [signalProcessingThread] WiredTigerKVEngine shutting down
 2016-06-15T00:47:54.436Z I STORAGE  [signalProcessingThread] shutdown: removing fs lock...
 2016-06-15T00:47:54.436Z I CONTROL  [signalProcessingThread] dbexit:  rc: 0

Como parte da configuração do serviço systemd, executei

systemctl --system daemon-reload
systemctl unmask mongodb.service
systemctl enable mongodb.service
systemctl start mongodb.service

Todos os dados, logs e diretórios de execução do mongodb são de propriedade do mongodb.mongodb - e eu criei um subdiretório mongodb de / var / run (possuído pelo mongodb)

O que está matando a versão systemd imediatamente após a inicialização?

Mais alguma coisa que eu possa tentar? (Eu tentei 'LimitNOFILE = 64000' em [Service])

Obrigado!

    
por Ali W 15.06.2016 / 03:33

2 respostas

2
  

processManagement: {fork: true, pidFilePath: "/var/run/mongodb/mongodb.pid"}

Esse é o seu problema. processManagement.fork deve ser false (que também é o padrão) no seu arquivo mongod.conf .

Porque é verdade, o mongod é completamente desnecessariamente bifurcado. Por ser o forking, o systemd está pensando que o processo principal do daemon saiu inesperadamente e está limpando o serviço de volta ao seu estado parado. Isso é feito encerrando explicitamente todos os processos filhos deixados pelo serviço. Daí o sinal.

Esta é uma incompatibilidade de protocolo de prontidão. O MongoDB não fala o protocolo de prontidão de bifurcação, e não é correto alterar a unidade de serviço systemd para dizer que sim. Em vez disso, é correto alterar a configuração do MongoDB para que ele não seja completamente desnecessário.

Leitura adicional

por JdeBP 15.06.2016 / 19:09
1

Normalmente - depois de caminhar por 20 minutos - voltei para algo em que venho trabalhando há horas e encontrei uma solução.

Type=forking

Necessário no arquivo /lib/systemd/system/mongodb.service. Que agora parece:

[Unit]
Description=High-performance, schema-free document-oriented database
After=syslog.target network.target

[Service]
Type=forking
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod -f /etc/mongod.conf
ExecStop=/usr/bin/mongod -f /etc/mongod.conf --shutdown

[Install]
WantedBy=multi-user.target

Espero que ajude alguém a sair!

    
por Ali W 15.06.2016 / 04:01