Memlockd is a daemon that locks files into memory. Then if a machine starts paging heavily the chance of being able to login successfully is significantly increased. The default configuration will lock all the files needed for login to a Debian GNU/Linux system via the console or via ssh.
- memlockd_1.3.1.tar.xz – Debian packaging updates
- memlockd_1.3.tar.gz – Debian packaging and systemd improcements
- memlockd_1.2.tar.gz – better systemd support, and added $ARCH as a config option
- memlockd_1.1.1.tar.gz – added systemd support
- memlockd_1.1.tar.gz
- memlockd_1.0.tar.gz
- memlockd_0.05.tar.gz
- memlockd_0.04.tar.gz
- memlockd_0.03.tar.gz
- memlockd_0.02.tar.gz
- memlockd_0.01.tar.gz
Hello,
Is it possible to run memlockd on CentOS 7?
Downloaded memlockd_1.1.tar.gz, extracted it and then did ‘make’.
Then copied memlockd on /etc/init.d and memlockd.cfg in /etc but it does not seem to run when I give /etc/init.d/memlockd -c /etc/memlockd.cfg .
I get the following in logs:
Recursion, entering “/etc/memlockd.d”
Can’t stat “/etc/memlockd.d”
it seemed that I just needed to create the folder /etc/memlock.d
I installed memlockd and I am satisfied that what I tell it to load it does. My problem is that I told it to load my desktop wallpapers and saw a jump in cache size – good.
I then repetitively changed the wallpaper and the disk gets busy and I was expecting all the wallpapers to come out of cache memory.
Debian 8.8.0 with KDE Desktop.
kernel 3.16.43-2+deb8u2.
Norman, what exactly is the problem here? Memlockd is supposed to lock everything in RAM and it sounds like it was doing that. It’s probably a bad idea to do that for wallpapers as your system should give better performance on average if they can be paged out. The aim of memlockd is to allow you to login as root to recover from a problem in an emergency, but of course I know that people will do things I didn’t plan for. ;)
Yes, wallpaper is not the best use for memlockd, but it shows a flaw in the system. The wallpapers should be coming out of the cache and not off the hard disk.
If wallpapers are read with normal read(2) syscall (e.g. with fread) and not mmap(2), then it is expected behavior.