Old admins think of systemd commands

My view echoes that of Carlos Fenollosa:

I had been riding the Linux wave for years, until I recently realized that my admin skills needed a total recycling. In a few years we've gone from /etc/init.d/sshd restart to service sshd restart to systemctl start sshd. That's a bit fast in my opinion, but I understand it's the price of progress, aimed to make computers boot faster and theoretically easier to administer for newcomers. Old admins, on the other hand, have a harder time adapting.

https://cfenollosa.com/blog/openbsd-from-a-veteran-linux-user-perspective.html


The writers of the systemctl commands and other systemd commands failed to consider the impact on old admins.



When you have hundreds of old scripts without systemctl commands, and you are forced to switch to systemd, what do you think?


Hello, command writers, please think of the impact on old admins before you write. If redirecting from service sshd restart to systemctl start sshd does the trick, please always keep this command redirection.

A start job is running for Raise network interfaces (long time / 5 minutes)

This is January 2017. "systemd" should not be used for critical missions.

When the network was down (without electricity), I noticed:

A start job is running for Raise network interfaces (long time / 5 minutes)

In /etc/systemd/system.conf,

#default
#DefaultTimeoutStartSec=90s

#changed
DefaultTimeoutStartSec=40s

#default
#DefaultTimeoutStopSec=90s

#changed
DefaultTimeoutStopSec=40s

These settings did not work as expected. It was a long waiting time.

Workaround: A stop / start job is running

A stop / start job is running ...

For this error, I do:


echo '' >> /etc/systemd/system.conf
echo 'DefaultTimeoutStartSec=6s' >> /etc/systemd/system.conf
echo 'DefaultTimeoutStopSec=6s' >> /etc/systemd/system.conf


systemctl reboot



This works for me.

Go back to sysvinit while keeping systemd

Latest workaround:

Another workaround.
If I want systemd, see the workaround above.

If I want to use sysvinit, continue...

---

This is June 2016. systemd is still not for me. My current workaround:

The command

aptitude install sysvinit-core init-select

Choose sysvinit.

What does the command do?

This helps me to use sysvinit instead. I could not boot or shut down properly with systemd. For shutting down and booting correctly, I use this workaround. I will try to test if the problem ceases to exist.

Time constraint

I don't have enough time to look for systemd issues and fixes. 

Not publicized
I don't know why this command above is not publicized here: (when a user wants to go back to sysvinit)

systemd - system and service manager
https://wiki.debian.org/systemd

No obvious choice when installing Debian

There is no option to choose between systemd and sysvinit when installing Debian Jessie.  (I don't know how to do this when installing.) I can hopefully switch after installing.

Remove systemd or not

This command below will cause packages that depend on systemd to stop working:

Some packages depend on systemd. (Sigh) I will not remove systemd by

apt-get remove --purge --auto-remove systemd

as seen here:

How to remove systemd from a Debian jessie/sid installation
http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation

Now, I go back to sysvinit while keeping systemd. More testing continues.

Workaround: A stop job is running for Avahi mDNS/DNS-SD stack

The error message appears when shutting down or rebooting the computer:
A stop job is running for Avahi mDNS/DNS-SD stack (seemingly forever/1 minute 55 seconds)

My temporary workaround:
systemctl stop avahi-daemon.service

# reboot
systemctl reboot


# shutdown
systemctl poweroff



Make this workaround above automatic:

Create a file:
nano /home/user_name/systemd_workaround.sh

The contents of the file:
#!/bin/bash
# systemd_workaround.sh


# explicitly stop this service:

/bin/systemctl --force stop avahi-daemon.service

Save:
Ctrl+x


Create another file:
nano  /lib/systemd/system/workaround.service



[Unit]
Description=cannot shut down or reboot properly
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target kexec.target


[Service]
ExecStart=/home/user_name/systemd_workaround.sh
Type=oneshot

Save:
Ctrl+x


Run this command:

chmod 755 /home/user_name/systemd_workaround.sh

Then, run this command:
systemctl daemon-reload

Now, shut down or reboot.
Instead of shutdown -r now, I entered
/bin/systemctl reboot

Instead of shutdown -h now, I entered
/bin/systemctl poweroff

Wow! Shut down and reboot properly. (I will observe and see if this is the best workaround.)


Update:

Latest workaround:

Another workaround.


---
Previously, I did...

If it was unfortunate, I would go back to sysvinit.



 I used:
/bin/systemctl poweroff

/bin/systemctl reboot
to test if it works. This method appeared to work. More testing continues. "A stop job is running" problem still exists. It occurs once every two or few weeks (already less frequently).


I had used:
/bin/systemctl --force stop avahi-daemon.service
to test if it works. Sorry, this reduced the frequency of the problem. This is still not the best workaround.

/bin/systemctl stop avahi-daemon.service
does not work as I expected.

Xfce on Debian Jessie 8.4 experiment again

I said it worked. Debian Jessie worked.

I still got 'A start job is running...' error that I had seen previously. No luck. I have seen this error on Debian (supposedly stable) and on Fedora (supposedly cutting edge).

This error showed that such process would run for, eh, the time of no limit. Scary and frustrating.

Then, I thought that this might be a kernel issue as Jessie depends on systemd. To be fair, systemd has caused a lot of changes to the kernel. These changes are somewhat risky, i.e., making the system fail to boot properly or making the system fail to shutdown properly.

Xfce depends on systemd especially when shutting down or restarting.

It looks as if Debian was not stable.

I temporarily upgrade the kernel and see no error. I will observe and see if this is the best workaround.

References:   

OpenRC and systemd? Which one?
http://mindmapapp.blogspot.com/2015/09/openrc-and-systemd-which-one.html

A start job is running for /boot
http://mindmapapp.blogspot.com/2015/09/a-start-job-is-running-for-boot.html

OpenRC and systemd? Which one?

I tried Fedora Linux for a few months in 2014. I got those "... job is running ..." or "... job is starting ..." messages when restarting / booting and the whole system stopped responding for more than five minutes.

These messages were largely the results of systemd.

systemd cannot be uninstalled without serious consequences. systemd is the default initialization system and all other spectacular control tools. systemd has replaced the former initialization system on Fedora Linux and subsequently the  initialization system on Debian Linux.

Debian Linux is suffering because of the replacement. Starting / restarting / stopping the system cannot show reliable results any more.

OpenRC is an alternative initialization system and is compatible with the old initialization system on Debian. I am trying to switch to OpenRC.


The good thing of OpenRC is: I can choose to stop the parallel start function. The parallel start function enables services to start at the same time.

Disabling the parallel start feature will lead to starting services one by one. Starting services one by one is good and stable. "No freezing machine. No hanging. "

systemd forces the parallel start of services. There is no option to stop the parallel start in systemd. Unpredictable hanging occurs. Debian 8 uses systemd. Debian 8 is no longer a stable system because of adopting systemd. If you need a stable system, Debian 8 is not for you. You might need to downgrade to Debian 7.

Debian 7 starts services one by one at boot time. Debian 7 is good.

OpenRC starts services one by one at boot time. OpenRC is used on Gentoo Linux I am trying to test and use. I have restarted Gentoo Linux on my machine for twenty times smoothly. "No freezing at boot time."

For future upgrading and large-scale deployment, Debian 8 is not my choice.

Maybe I need Gentoo Linux and I need to learn to be an advanced administrator to use Gentoo Linux. The Gentoo Linux community provides a lot of documentation. Such documentation will definitely help me to learn quickly.

I need to set aside two machines for Gentoo Linux. One for testing and one for real deployment. To be an advanced administrator, I need to test the packages first before applying them on the production server.

On the contrary, "aptitude update && aptitude safe-upgrade" is used on Debian. I simply trust the maintainers. My trust is justified by experience. No problems after the "safe upgrade".

The key issue is: Debian 8 is not stable even in the "stable" release now. systemd causes a lot of stability headaches.

I will see if Gentoo Linux will help. OpenRC is good as in my experiment. Gentoo Linux uses OpenRC and not systemd by default. Definitely I need to consider Gentoo Linux.