My Issue
I am having trouble removing MongoDB warnings about Transparent Huge Pages (THP) on an OVH CentOS 7 installation, and the issue appears to be the inability to write to /sys/kernel/mm as root.
First, I realize the OVH kernel is customized, and I know many of you will say to go with a fresh non-customized kernel, but that's not an option right now. I need to solve this problem for the current OS.
MongoDB Warnings:
2016-03-09T00:31:45.889-0500 W CONTROL [initandlisten] Failed to probe "/sys/kernel/mm/transparent_hugepage": Permission denied
2016-03-09T00:31:45.889-0500 W CONTROL [initandlisten] Failed to probe "/sys/kernel/mm/transparent_hugepage": Permission denied
MongoDB is trying to read the transparent_hugepage files (below), but they do not exist:
/sys/kernel/mm/transparent_hugepage/enabled
/sys/kernel/mm/transparent_hugepage/defrag
Cannot Create the Files
All of the solutions I've seen involve creating the files and populating them with never, including the script in the MongoDB documentation. In all of the solutions, this is the key part:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
However, the files do not exist, and I cannot create anything under /sys/kernel/mm as root.
root#myhost [~]# echo never > /sys/kernel/mm/transparent_hugepage/enabled
-bash: /sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
root#myhost [~]# mkdir -p /sys/kernel/mm/transparent_hugepage
mkdir: cannot create directory ‘/sys/kernel/mm/transparent_hugepage’: Operation not permitted
The owner and group of directory /sys/kernel/mm are root, and I have temporarily changed the permissions from 700 to 777, yet I still cannot create the directory as root.
Tuned Profile Also Doesn't Help
To be thorough, I have also created the custom Tuned profile (per instructions in MongoDB link above) and activated it, but it generates the error WARNING tuned.plugins.plugin_vm: Option 'transparent_hugepages' is not supported on current hardware.
Tuned Profile (/etc/tuned/no-thp/tuned.conf):
[main]
include=virtual-guest
[vm]
transparent_hugepages=never
Error in Tuned log:
WARNING tuned.plugins.plugin_vm: Option 'transparent_hugepages' is not supported on current hardware.
Some Solution in MongoDB Itself?
It seems like the best solution would be to somehow explicitly configure MongoDB not to use THP so that it wouldn't have to check for the missing files, but I've seen nothing like this. If there is a way, even if it involves customizing MongoDB (and repeating after every update), I'm willing to do it.
Right now I've installed CentOS 7 on OVH. They use /boot/bzImage-3.14.32-xxxx-grs-ipv6-64 that implements grsecurity (https://grsecurity.net) which precludes access to some folders.
The very simple solution to the warnings from MongoDB about huge pages can be solved by replacing the kernel. The procedure for CentOS7 is as follows:
Download required kernel from OVH ftp: ftp://ftp.ovh.net/made-in-ovh/bzImage2 into /boot folder.
Edit /etc/grub2.cfg:
# linux /boot/bzImage-3.14.32-xxxx-grs-ipv6-64 root=/dev/md1 ro net.ifnames=0
linux /boot/bzImage-4.8.17-xxxx-std-ipv6-64 root=/dev/md1 ro net.ifnames=0
Here I replaced bzImage-3.14.32-xxxx-grs-ipv6-64 default by bzImage-4.8.17-xxxx-std-ipv6-64 without grs.
Now, reboot and check if the new kernel is ok:
root#ns506846 ~]# uname -r
4.8.17-xxxx-std-ipv6-64
Related
As explained I want to set up a PostgreSQL database (specifically for Metasploit to use as I'm running my own install of arch instead of kali linux). I have followed the instructions so far to the best of my ability although I don't have any experience with PostgreSQL or much in databases for that matter and am stuck on this error.
As you can see the server was able to be initialised at least but I don't know how to/can't get it to start.
[postgres#rt metasploit]$ initdb --locale=C --encoding=UTF8 -D /var/lib/postgres/data --data-checksums
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "C".
The default text search configuration will be set to "english".
Data page checksums are enabled.
creating directory /var/lib/postgres/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/GMT-2
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
Success. You can now start the database server using:
pg_ctl -D /var/lib/postgres/data -l logfile start
[postgres#rt metasploit]$ pg_ctl -D /var/lib/postgres/data -l logfile start
waiting for server to start..../bin/sh: line 1: logfile: Permission denied
stopped waiting
pg_ctl: could not start server
Examine the log output.
If this is a noob question please just link me to the answer, as I said I have little to no experience working with databases and just want to get it up and running. I tried searching for it myself but couldn't find much of help.
I've been working on a file server product that uses smbcilent to transfer files between client computers and the server. It's been working great so far with our LAMP (Ubuntu) server and Windows machines.
I'm currently trying to expand the setup to include Mac's, but am having trouble with the server accessing the share on the Mac.
Here's my command and error (bracketed descriptions replace private info):
# smbclient //10.101.0.7/[share-file] -U [username]%[password] -c ls
WARNING: The "syslog" option is deprecated
NTLMSSP packet check failed due to short signature (0 bytes)!
NTLMSSP NTLM2 packet check failed due to invalid signature!
session setup failed: NT_STATUS_ACCESS_DENIED
Things I've tried:
✓ Accessing share using a Windows machine to ensure the share is setup properly - check! Works fine there.
✓ Invoking -S off or --signing=off in the command - no change.
✓ Just looking at the shares first using smbclient -L 10.101.0.7 -U [username]%[password] - same error.
✓ Googling for an answer - check! Several people with similar problems, but no working solutions so far.
The most promising thing I've see so far involves compiling smbclient 4.4 from sources and running that with no authentication (-U ""%""), but that seems like a temporary solution based on a bug rather than a solid plan that will work for a long time. (But I'll try that next if I can't find any better ideas...)
Thanks for reading and trying to help!
Try adding --option="ntlmssp_client:force_old_spnego = yes" to the smbclient command as suggested on the samba-technical mailing list.
For me, this now lists shares on a Mac OSX server:
smbclient -U$user%$password -L $mac_host --option="ntlmssp_client:force_old_spnego = yes"
For mounting, you may need to add the nounix,sec=ntlmssp options as in
sudo mount -t cifs //$mac_host/$share $mountpoint -o nounix,sec=ntlmssp,username=$user,password=$password
On recent versions of MacOS (e.g. Monterey) it is necessary to do several configuration steps to enable smb access from Linux:
Open System Preferences.
Select Sharing.
Select File Sharing.
Ensure that the directory is listed in Shared Folders.
Right-click/two-finger click on the share directory.
Click on Advanced Options
Ensure Only allow SMB encrypted connections is checked.
Click OK
Click on Options
Click on the checkbox for Share files and folders using SMB.
Under Windows File Sharing ensure the appropriate user is checked.
Type the user's password in the 'Authenticate' dialog bo and press 'OK'.
Click 'Done'.
You should now be able to connect from Linux to the MacOS share using the commands given by #mivk.
Several identical machines all running Fedora 21 in a cluster are all exhibiting identical issues:
Attempting to pull a user journal with journalctl -r gives:
No journal files were opened due to insufficient permissions.
Trying journalctl --user -r gives:
No journal files were found.
Checking in /var/log/journal/[whatever] yields system journals (which seem to work fine as root) and one or two user journals. Logging in as a user that has a user journal in this directory shows that these users can pull their own journal just fine.
It seems like journals are being created for some users but not others. I can find nothing different about the users with journals, and it's not the same users exhibiting the problem on every system, despite identical /etc/passwd, /etc/group, and /etc/shadow files across the systems.
All of this worked fine on Fedora 20.
I believe this is related to this question.
I had this issue on Ubuntu 17.10. One of my users could view his journal entries, but another couldn't. The issue was resolved by changing the Storage directive of the [Journal] section of /etc/systemd/journald.conf to persistent:
Edit journald.conf
$ sudo vi /etc/systemd/journald.conf
Original Config
[Journal]
#Storage=auto
...
New Config
[Journal]
Storage=persistent
...
After a restart of journalctl, all users could view their respective logs:
$ sudo systemctl restart systemd-journald
Agenda: To have an common Project Folder between Linux and Windows
I have changed my document root from : /var/www/html to /media/mithun/Projects/test in my ubuntu machine 14.04
I get error as :
Forbidden
You don't have permission to access / on this server.
Apache/2.4.7 (Ubuntu) Server at localhost Port 80
So i added some scripts to : sudo gedit /etc/apache2/sites-available/000-default.conf
# DocumentRoot /var/www/html
DocumentRoot /media/mithun/Projects/test
But Document Root /var/www/test works but not with Windows NTFS Partition Drive.
Even after referring to :
Error message "Forbidden You don't have permission to access / on this server"
Issue with my Ubuntu Apache Conf file. (Forbidden You don't have permission to access / on this server.)
No success :( So kindly assist me with it...
Note: Projects is an New Volume (Internal Drive: In Windows its E:/ Drive)
#Lmwangi - Please check my updates for your reference below:
Output of : ls /etc/apparmor.d/
abstractions lightdm-guest-session usr.bin.evince usr.sbin.cupsd
cache local usr.bin.firefox usr.sbin.mysqld
disable sbin.dhclient usr.lib.telepathy usr.sbin.rsyslogd
force-complain tunables usr.sbin.cups-browsed usr.sbin.tcpdump
I tried killing apparmor:
sudo /etc/init.d/apparmor kill
I receive output as : Usage: /etc/init.d/apparmor
{start|stop|restart|reload|force-reload|status|recache}
After this, i was also able to restart apache successfully
maybe the problem is simple : is your new root directory accessible to the www-data user ?
Try :
$ chown -R www-data:www-data /media/mithun/Projects
As you have you have discovered by now, you cannot just manipulate permissions on an NTFS partition (using tools like chmod)
However, you can try forcing a given owner/permissions for the entire partition when you mount it.
Now the wayto do this, depends on the NTFS-utilities you are actually using (and which i don't know, so I'm assuming you are using ntfs-3g)
E.g. mount the partition with the following parameters (replace dev/sdX with your actual partition, and /path/to/wheredrive/is/mounted` with your target path):
mount -o gid=www-data /dev/sdX /path/where/the/drive/is/mounted
should make all the files on the partition belong to the www-data group.
If the filesystem sets the group ownership explicitely, this still might not work.
In this case, you might need to setup a usermap, that maps your windows users/groups (as found on the partition) to your linux users/groups.
The ntfs-3g.usermap utility will help you generate an initial usermap file, which you can then edit to your needs:
ntfs-3g.usermap /dev/sdX
Then pass the usermap to the mount options:
mount -o usermapping=/path/to/usermap.file /dev/sdX /path/where/the/drive/is/mounted
I suspect that you have apparmor enforcing rules that prevent Apache from reading non-whitelisted directory paths. I suggest that you
Edit the apparmor config for Apache to access your custom path. You'll need to hunt around /etc/apparmor.d/ . You may also find that using apparmor in non-enforcing mode helpful.
$ sudo aa-complain /etc/apparmor.d/*
Use mod_apparmor? See this
Or disable apparmor completely. See this
My order of preference would be 1,3,2. That should fix this for you :)
While using ubuntu with windows I faced same issue and it is resolved by remounting drive with read and write access. Below command will help you to do that:
sudo mount -o remount,rw /disk/location /disk/new_location
If it is still not working then in windows os, go to the power options and disable fast startup.
When you shut down a computer with Fast Startup enabled, Windows locks down the Windows hard disk. You won’t be able to access it from other operating systems if you have your computer configured to dual-boot. Even worse, if you boot into another OS and then access or change anything on the hard disk (or partition) that the hibernating Windows installation uses, it can cause corruption. If you’re dual booting, it’s best not to use Fast Startup or Hibernation at all.
Original article: https://www.howtogeek.com/243901/the-pros-and-cons-of-windows-10s-fast-startup-mode/
A few questions are already asking about how to fix the mongodb warning:
** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always.'
** We suggest setting it to 'never'
But I'm wondering if it should be fixed. I get this warning from MongoDB 3.0.1 on a Ubuntu VM running on Google's Cloud. Should I trust MongoDB that 'never' is better? Or should I trust Google/Ubuntu that they set it to 'always' for a good reason? I imagine there are tradeoffs to be considered and don't know what I'd be trading to keep it or fix it.
Asking how to fix it is fine, but asking whether to fix it seems wiser.
Edit: Mongodb have addressed this issue since I wrote this answer. Their recommendation is at https://docs.mongodb.com/master/tutorial/transparent-huge-pages/ and probably ought to be your go-to solution. My original answer will still work, but I'd consider it a hack now that an official solution is available.
Original answer: According to the MongoDB documentation, http://docs.mongodb.org/manual/reference/transparent-huge-pages/, and support, https://jira.mongodb.org/browse/DOCS-2131, transparent_hugepage (THP) is designed to create fewer large memory blocks rather than many small memory blocks in systems with a lot of memory. This is great if your software needs large contiguous memory accesses. For MongoDB, however, regardless of memory available, it requires numerous smaller memory accesses and therefore performs better with THP disabled.
That makes me think either way will work, but you'll get better mongo (or any database) performance with THP off, giving you smaller bites of memory. If you don't have much memory anyway, THP probably ought to be off no matter what you run.
Several ways to do that are outlined in the link above. The most universally applicable appears to be editing rc.local.
$ sudo nano /etc/rc.local
Insert the following lines before the "exit 0" line.
...
if test -f /sys/kernel/mm/transparent_hugepage/khugepaged/defrag; then
echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi
if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
exit 0
Note: redhat-based systems may use "redhat_transparent_hugepage" rather than "transparent_hugepage" and can be checked by:
ls /sys/kernel/mm/*transparent_hugepage*/enabled
cat /sys/kernel/mm/*transparent_hugepage*/enabled
To apply the changes, reboot (which will run rc.local) or:
$ sudo su
# source /etc/rc.local
# service mongod restart
# exit
to properly apply the changes made above
For Ubuntu using upstart scripts:
Since we are deploying machines with Ansible I don't like modifying rc files or GRUB configs.
I tried using sysfsutils / sysfs.conf but ran into timing issues when starting the services on fast (or slow machines). It looked like sometimes mongod was started before sysfsutils. Sometimes it worked, sometimes it did not.
Since mongod is an upstart process I found that the cleanest solution was to add the file /etc/init/mongod_vm_settings.conf with the following content:
# Ubuntu upstart file at /etc/init/mongod_vm_settings.conf
#
# This file will set the correct kernel VM settings for MongoDB
# This file is maintained in Ansible
start on (starting mongod)
script
echo "never" > /sys/kernel/mm/transparent_hugepage/enabled
echo "never" > /sys/kernel/mm/transparent_hugepage/defrag
end script
This will run the script just before mongod will be started.
Restart mongod (sudo service mongod restart) and done.
In Ubuntu I used the option 'Init Script' of this document: http://docs.mongodb.org/manual/tutorial/transparent-huge-pages/
None of these worked for me on Amazon ec2 instance running Ubuntu 14.04, not even the init.d script recommended by MongoDB. I had to use the hugeadm tool by first installing it via apt-get and then running sudo hugeadm --thp-never, this post pointed me to hugeadm. I'm still trying to figure out how to disable the transparent_hugepage defrag. hugeadm doesn't seem to have an easy way to do that.