For almost two years Mike Rapoport and I have been working on lazy process migration. Lazy process migration (or post-copy migration) is a technique to decrease the process or container downtime during the live migration. I described the basic functionality in the following previous articles:

Those articles are not 100% correct anymore as we changed some of the parameters during the last two years, but the concepts stayed the same.

Mike and I started about two years ago to work on it and the latest CRIU release (3.5) includes the possibility to use lazy migration. Now that the post-copy migration feature has been merged from the criu-dev branch to the master branch it is part of the normal CRIU releases.

With CRIU’s 3.5 release lazy migration can be used on any kernel which supports userfaultfd. I already updated the CRIU packages in Fedora to 3.5 so that lazy process migration can be used just by installing the latest CRIU packages with dnf (still in the testing repository right now).

More information about container live migration in our upcoming Open Source Summit Europe talk: Container Migration Around The World.

My pull request to support lazy migration in runC was also recently merged, so that it is now possible to migrate containers using pre-copy migration and post-copy migration. It can also be combined.

Another interesting change about CRIU is that it started as x86_64 only and now it is also available on aarch64, ppc64le and s390x. The support to run on s390x has just been added with the previous 3.4 release and starting with Fedora 27 the necessary kernel configuration options are also active on s390x in addition to the other supported architectures.

As I’m currently switching phones I had to revisit the issue of how to get sshd running on a pristine LineageOS install. I decided to collect the steps here as the how-to formerly available on the CM wiki has vanished together with CM itself. Note that some  steps are not incredibly detailed and you really should be aware of the security implications before going ahead with this.


Configuring SSHD

While LineageOS includes all necessary software, the configuration of sshd must be completed manually:

  1. Connect the device via USB
  2. Run adb with root privileges:
    adb root
  3. Upload your public ssh key to the device:
    adb push ~/.ssh/ /data/ssh/authorized_keys
  4. Now, open a root shell and switch to bash to get vim to behave nicely on the device through adb:
    adb shell
  5. Use cat or vim to make the following fragment the contents of /data/ssh/sshd_config:

    AuthorizedKeysFile /data/ssh/authorized_keys
    ChallengeResponseAuthentication no
    PasswordAuthentication no
    PermitRootLogin no
    Subsystem sftp internal-sftp
    pidfile /data/ssh/

  6. Place a modified version of the start script in the userinit.d directory:
    mkdir /data/local/userinit.d
    sed 's#/system/etc/ssh#/data/ssh#' /system/bin/start-ssh
          > /data/local/userinit.d/99sshd
  7. Now correct the file privileges:
    chmod 755 /data/local/userinit.d/99sshd
    chmod 600 /data/ssh/authorized_keys
    chown shell /data/ssh/authorized_keys
    chmod 644 /data/ssh/sshd_config

Running SSHD

Now you should be able to run sshd manually by executing
If so you can log on as user shell to the device using your ssh key. See my previous post to find out how you can make sure sshd is started whenever the device is booted.

It is a bit late but I still wanted to share my presentations from this year’s Linux Plumbers Conference:

On my way back home I had to stay one night in Albuquerque and it looks like the hotel needs to upgrade its TV system. It is still running Fedora 10 which is EOL since 2009-12-18:

Still Fedora 10

To restore a checkpointed process with CRIU the process ID (PID) has to be the same it was during checkpointing. CRIU uses /proc/sys/kernel/ns_last_pid to set the PID to one lower as the process to be restored just before fork()-ing into the new process.

The same interface (/proc/sys/kernel/ns_last_pid) can also be used from the command-line to influence which PID the kernel will use for the next process.

# cat /proc/sys/kernel/ns_last_pid
# echo -n 9999 > /proc/sys/kernel/ns_last_pid
# cat /proc/sys/kernel/ns_last_pid

Writing ‘9999’ (without a ‘new line’) to /proc/sys/kernel/ns_last_pid tells the kernel, that the next PID should be ‘10000’. This only works if between after writing to /proc/sys/kernel/ns_last_pid and forking the new process no other process has been created. So it is not possible to guarantee which PID the new process will get but it can be influenced.

There is also a posting which describes how to do the same with C: How to set PID using ns_last_pid