New answers tagged

0

It turned out the huge number of httpd processes, open connections and the consequential high CPU load somehow resulted from an old and broken SSL configuration (duplicate VirtualHost with different expired certificates) in Apache's conf.d folder. Since there were no error messages at all I triple-checked the configurations and made some trial-and-error ...


0

A node can only have one value value for a given attribute (such as node["susemongodb"]["node_nickname"]) and the values are determined during the compile phase (see "Stages" here). So in your case, and assuming there are no overrides with higher precedence, the values from the last role in the run-list will be used. In addition, before starting the ...


1

I made wrong assumptions about the internet connection of my company. Port 27017 is blocked. I solved the problem by using an open port instead.


0

You can see what directories php looks for ini files in with the --ini flag. Here is an example on the php:5-apache image: root@2ca6abaef312:/var/www/html# php --ini Configuration File (php.ini) Path: /usr/local/etc/php Loaded Configuration File: (none) Scan for additional .ini files in: /usr/local/etc/php/conf.d Additional .ini files parsed: ...


1

You can designate a old server using the [--host option in mongodump][1] on your new / separate computer with the available disk space. This simply initiates the dump from the new machine and stores it there. In MongoDB 3.2 the tools offer the ability to use [standard output][2], in this case if you wanted to initiate the dump on the new machine and then ...


0

Simply the config that stops this from happening hasn't been applied: logRotate: reopen As the mongo service hadn't been restarted since the config had been updated. After a restart of the service the next rotation only created a single log file.


0

In your configuration your log is being rotated twice. First time when you send SIGUSR1 to mongo instance and second time via logrotate. So logrotate rotates empty log just created by mongo. One doesn't need logrotate to rotate mongo log because mongodb can do it by its own. I set up rotation this way [mongod@lab7-mongo-4 ~]$ crontab -l 00 00 * * * ...


1

As everything including the journal is on the same storage device (i.e. your dbpath is not mapped to multiple EBS volumes) then you don't need flush and lock the database. This is only the case where these are spread across multiple volumes. Assuming the journal is present on the same volume as the data files, a snapshot will capture both the state of the ...


0

Since mongodb 3.0 you can change the behavior of mongodb with the logRotate parameter, change in /etc/mongod.conf systemLog: logAppend: true logRotate: reopen See also Mongo Manuals. Then you can use this logrotate configuration: /var/log/mongodb/*.log { daily rotate 30 size 50M compress dateext missingok notifempty ...



Top 50 recent answers are included