With systemd 230, released a couple of days ago, the developers changed a default setting, that eliminates one of the few annoyances I experienced with systemd. Many a forum thread all over the net tried to solve the problem. This annoyance resulted in a message during reboot or shutdown, that the system is waiting for a process to shut down. This could take up to 90 seconds, if you did not set the level lower manually. These were stray background processes, that belonged to one or more users on the system and should have been shut down, when the owning user gets logged out.
The systemd developers with systemd 230 set the option
yes. That means that 95 percent of desktop users will not see these delays anymore, because all processes of a user will be closed when the user gets logged out. On the other hand, users of tools like screen, tmux and some others will find their processes also killed server-side, even though these were meant to be long-running background jobs. That being said, the devs did explain in the release note for systemd 230 under the third bullet, what users of such tools need to do to keep
yes and still have their long-running jobs stay alive. The problem at hand was being layed out in detail in a bugreport and it’s follow-up discussion already in April.
In Debian and Fedora this new behaviour led to long discussions (and the usual systemd laments of course). The bug report for Debian on this matter now led to the new standard setting being reverted in Debian with systemd 230-2 as of today. So, if you like your processes being stopped when your user logs out, you need to manualy revert the setting in /etc/systemd/logind.conf to yes again after updating to systemd 230-2. We decided months ago to have this set to
yes as default for siduction. This will take effect with our next release. But if you want to set this to
yes now, you need to do so yourself.
Should you be one of the users of screen, tmux, mosh and maybe a few other affected tools, there is ways to keep the setting at yes and still keep long running processes alive when logging out. You need two things to do this: first you set
enable-linger [USER1 USER2...] for your respective users, as shown in the manpage to
loginctl. PAM has been adapted to allow this as normal user. Then you can follow the manpage of
systemd-run to start e.g. screen with the command
systemd-run --scope --user screen in it’s own scope. This will keep the job running after logout, even though other user processes are stopped.
We admired Debian for deciding pro systemd, but we think, reverting this new default is the wrong decision in the face of desktop users.
Last week i stumbled upon a interesting project: The liberation of the Debian Administrator’s Handbook. The goal of the project is described best with their own words:
Liberate the Debian Administrator’s Handbook
The Debian Administrator’s Handbook has been written by two Debian developers who are keen to share their knowledge. Accessible to all, this book teaches the essentials to anyone who wants to become an effective and independent Debian GNU/Linux administrator.
It covers all the topics that a competent Linux administrator should master, from the installation and the update of the system up to building packages and the compilation of the kernel, but also monitoring, backup and migration, without forgetting advanced topics like SELinux setup to secure services, automated installations, or virtualization with Xen, KVM or LXC.
Read more at http://debian-handbook.info/liberation
Since KDE SC 4.7 transition ist still blocked in Debian, preventing 4.7.4 moving from experimental to unstable, this leaves unstable users with an unsatisfying KDE SC 4.6.5. For our first release, we had used the debian-qt-kde repository, which at the time had KDE SC 4.7.2. Soon after, KDE SC 4.7.4 got uploaded to experimental. Instead of also updating the qt-kde repo, it was emptied and is dead in the water at the moment. The god thing about the qt-kde repo is, that it needs on very basic 3 lines of pinning.
As things look right now, we will see KDE SC 4.7.x in Debian 7 Wheezy. As the freeze for that is not so far away, that could mean, that KDE SC 4.8 will not enter any debian repo for a while, because in freeze RC-Bugs have priority. Even though 1 guy is working on KDE SC 4.8, there might not be enough time and manpower, once freeze hits us.
For a user to use KDE SC 4.7.4 from debian experimental, user needs a preferences file, pinning every package, resulting in a list as long as my arm. To resolve the situation, we have decided to set up a repository calles kde-next, which, at the moment, holds the KDE SC 4.7.4 packages. Adding this repo to your sources.list.d will update your kde-version to KDE SC 4.7.4 with your next dist-upgrade. No need for pinning. The upgrade from KDE SC 4.7.2 to 4.7.4 is, as can be expected, a breeze. Should you want to upgrade from KDE SC 4.6.5, or – behold – even older, please be careful and read what apt wants to do.
The lines to add are:
- deb http://packages.siduction.org/kdenext unstable main
- deb-src http://packages.siduction.org/kdenext unstable main
After an apt-get update your package-manager is introduced to the repository and you are good to go.
After a few days of downtime or partial downtime WordPress has surrendered to agaidas thorough strive to have this blog bilangual in german and english. The english section is availabe at http://news.siduction.org, whereas the germal part is at http://de.news.siduction.org. some minor work is still to be done, in the backend as well as visualy, but no more downtime is to be expected. Thanks agaida for not giving up 🙂