| Tarball: | criu-1.8.tar.bz2 |
| Version: | 1.8 |
| Released: | 7 Dec 2015 |
| GIT tag: | v1.8 |
New features
- Ability to check CRIU features via RPC
- New zdtm.py test suite
- Pre-dump and pre-restore action scripts
- The "info" action in CRIT showing stats about image file
- More user-friendly output by CRIT
- Python API -- pycriu
- Ability to add custom paths to irmap scan
- C/R of
- read-only bind mounts
- IPv6 routes and iptables rules
- ip rules (it ip tool supports such)
- ignore_routes_with_linkdown netns devconf
- empty bridges in netns
Optimizations/improvements
- Shared pie/non-pie .c files are built two times with proper flags
- VDSO code re-shuffled for better re-use between arches
- Failures of action scripts are reported in logs
- OpenVZ's VENET handling is tuned to fit the current kernel state
- Do not use hardcoded /dev/rts maj:min numbers
- Unsupported socket protocols are reported at expected place
- Slightly faster access to /proc files by using O_PATH open mode
- Improved page-server dump speed by keeping control over the Nagle algorithm
- Read pages.img in more optimal manner rather than page-by-page
Fixes
- Page server flooded node with tw buckets during migration
- Turned off cgroups controllers weren't detected as such
- Netns sysctls from old images weren't properly restored
- Running process could be mistakenly stopped after --leave-running dump
- Helper processes run by CRIU produced fake error messages in logs
- Error code from sigaction restore could be missed
- Several potential buffers overruns due to missed '\0' after strcpy-s existed
- Killed processes after dump survived in zombie state for some time holding PIDs and resources
- If task had MANY children, the latter could be skipped on dump
- Task dying while being frozen could fail the dump
- On Aarch64 the upper limit for user memory was not properly detected sometimes
- Guess for TCP buffer max segment size was too optimistic (could fail the restore on low-mem machines)
- CRIT didn't decode userns images
- Ghost files were left in the FS tree after failed restore (blocking the next restore attempt)
- Some log messages from pie code were lost
- Some net/ipc/uts sysctls failed to restore in userns
- Move tasks int cgroups failed in userns
- Unsupported filesystems silently failed the dump
- External tmpfs (and some other) mounts generated tarballs with their contents
Security
- Service run as root could allow users to violate ptrace policies
- Service run as root could give users access to privileged files and directories