Enabling CRIU on CloudLinux + cPanel EA4
IMPORTANT!! CRIU may cause stability issues! Enable CRIU AT YOUR OWN RISK!
Checkpoint/Restore In Userspace, or CRIU, is an open source project which dumps all of the information of a running process to disk and restores it at the point of the dump. The LiteSpeed Enterprise Edition Web Server now supports CRIU for the CloudLinux implementation of the PHP processor.
However, generally, we don't recommend you enable CRIU unless you have a special requirement for it. CRIU uses significant server resources and may generate unusual errors while providing no performance benefits.
We have received quite a few reports that potential bugs on the CRIU module may cause web server stability issues. Please permanently disable CRIU, or enable CRIU AT YOUR OWN RISK.
Requirements
- CloudLinux System
- ea-apache24-mod_lsapi 1.1 on cpanel EA4 (or mod_lsapi on cPanel EA3) or above
- LiteSpeed Web Server 5.3 or above.
Installation
Verify CRIU is enabled on your system
Criu is installed with dependency to ea-apache24-mod_lsapi for cpanel EA4( or mod_lsapi for cpanel EA3) 1.1 and above package.
If you have not installed it, you should:
yum install liblsapi liblsapi-devel
============================================================================================================================================================================= Package Arch Version Repository Size ============================================================================================================================================================================= Installing: liblsapi x86_64 1.1-28.el7.cloudlinux cloudlinux-x86_64-server-7 180 k liblsapi-devel x86_64 1.1-28.el7.cloudlinux cloudlinux-x86_64-server-7 37 k Installing for dependencies: crit-lve x86_64 3.7-3.el7 cloudlinux-x86_64-server-7 9.6 k criu-lve x86_64 3.7-3.el7 cloudlinux-x86_64-server-7 439 k criu-lve-devel x86_64 3.7-3.el7 cloudlinux-x86_64-server-7 11 k libnet x86_64 1.1.6-7.el7 cloudlinux-x86_64-server-7 58 k protobuf-c x86_64 1.0.2-3.el7 cloudlinux-x86_64-server-7 27 k protobuf-python x86_64 2.5.0-8.el7 cloudlinux-x86_64-server-7 129 k python-criu-lve x86_64 3.7-3.el7 cloudlinux-x86_64-server-7 136 k python-ipaddr noarch 2.1.11-1.el7 cloudlinux-x86_64-server-7 34 k Transaction Summary ============================================================================================================================================================================= Install 2 Packages (+8 Dependent packages)
yum install ea-apache24-mod_lsapi
Check CRIU whether the service is running or not.
ps -ef | grep criu root 967641 1 0 19:24 ? 00:00:00 /usr/sbin/criu service -v4 -o /var/log/criu-service.log --address /var/run/criu/criu_service.socket root 967680 965818 0 19:24 pts/1 00:00:00 grep --color=auto criu
If not, enable by following method:
systemctl enable criu systemctl start criu systemctl status criu
Output should be Active: active (running)
.
[root@globalsupport ~]# systemctl status criu ● criu.service - Checkpoint Restore in Userspace daemon Loaded: loaded (/usr/lib/systemd/system/criu.service; disabled; vendor preset: disabled) Active: active (running) since Mon 2018-08-20 19:24:25 UTC; 4min 23s ago Process: 967640 ExecStartPre=/bin/mkdir -p /var/run/criu (code=exited, status=0/SUCCESS) Main PID: 967641 (criu) CGroup: /system.slice/criu.service └─967641 /usr/sbin/criu service -v4 -o /var/log/criu-service.log --address /var/run/criu/criu_service.socket
Aug 20 19:24:25 globalsupport.litespeedtech.com systemd[1]: Starting Checkpoint Restore in Userspace daemon... Aug 20 19:24:25 globalsupport.litespeedtech.com systemd[1]: Started Checkpoint Restore in Userspace daemon. Aug 20 19:24:25 globalsupport.litespeedtech.com criu[967641]: Warn (criu/kerndat.c:660): Can't load /run/criu.kdat
CRIU Master Switch on LSWS
CRIU is disabled by default. To enable it, you can go to LSWS Web Admin Console → Server → PHP → PHP Global Configuration → Enable CRIU( Again, we recommend you keep CRIU off unless you have some speical testing need only).
Check CRIU parameters
In CloudLinux, LSPHP have been compiled with CRIU already. Please check here
Use phpinfo()
with parameter -DWITH_CRIU
to check the LSPHP build.
Configure the PHP environment
Add the following necessary parameter to the PHPx.x External App > Environment
LSAPI_CRIU=1
Important Syntax
Variable | Values | Default | Description |
---|---|---|---|
LSAPI_CRIU | 1/On/Off | Off | If set to On, CRIU will be performed. 1=On |
LSAPI_INITIAL_START | A number from 1 upwards. | 15 | The number of consecutive calls which must be made within a single PHP instance before a dump of the instance will be made. If there’s no PHP instance running and there’s a dump on disk it will be restored on the first use. |
LSAPI_CRIU_IMGS_DIR_PATH | Any valid, existing directory | /var/run/lsws/cl_criu/ | CRIU images will start from this directory; a subdirectory named “images” will be created below and then a directory for each user's type of request. There needs to be lots of free space in this file system. |
LSAPI_CRIU_DEBUG | On/Off | Off | If set to On , messages concerning CRIU processing will be written to the stderr.log file (usually in /usr/local/apache2/logs/stderr.log) |
How to Verify
Step 1
- Prepare any PHP site, e.g. WordPress
Step 2
- Generate the dump by hitting the WordPress site
- Hit more than INITIAL_START number, e.g. 20 times
- If an image dump is generated, you should see an image folder under
/var/run/lsws/cl_criu/
Step 3
- Check the PHP process number by
ps -ef | grep php >>> user 868577 ... 10:54 0:00 lsphpL
- Kill the lsphp process via
kill -9 868577
Step 4
- Restore the PHP by refreshing the WordPress page to regenerate it
- Verify the process number is the same as before:
ps -ef | grep php >>> user 868577 ... 10:55 0:00 lsphp
The process is back!!
- You can also check standard error log for something like
LSCRIU: Successful CloudLinux dump of PID: 868577 LSCRIU: Successful CloudLinux restore of PID: 868577, parent: 1.
Logs
- Error log default located at Apache standard error log
dump.log
is in the images directoryrestore.log
is in the images directory
NOTE: restore.log
is generated even when there is no dump, so it's expected to see some related fail logs