Krasser Spass mit systemd

[Tim Ritberg]

Hi!

Ach ja, Montag morgens Spass mit systemd.

Auch der Hoster könnte der Übeltäter sein.
Ich hab dieses merkwürdige Problem nur bei dieser Kiste: Ubuntu 22.04
als DNS-Server mit bind9.

Ein anderer DNS-Server mit Ubuntu 22.04 und bind9 bei einem anderen
Hoster hat dieses Problem nicht. Beide Server gleich eingerichtet, wobei
das Init-Setup jeweils vom Hoster kam.

Die Sorgenkiste gerät ins Trudeln, sobald bestimmte Updates installiert
werden. Es sind scheinbar systemd-Pakete. Dann geht der Horror los:
"Job for ssh.service failed because the control process exited with
error code.
See "systemctl status ssh.service" and "journalctl -xeu ssh.service" for
details."

Damit ist ssh tot und die Kiste nicht mehr steuerbar -> reboot

Log sagt:
Apr 17 09:14:20 ns2 systemd[1]: ssh.service: Found left-over process 970
(sshd) in control group while starting unit. Ignoring.
Apr 17 09:14:20 ns2 systemd[1]: This usually indicates unclean
termination of a previous run, or service implementation deficiencies.

Und weiter in rot:
Apr 17 09:14:20 ns2 sshd[1324545]: error: Bind to port 22 on 0.0.0.0
failed: Address already in use.
Apr 17 09:14:20 ns2 sshd[1324545]: fatal: Cannot bind any address.

Und dann noch ganz viel minutenlang:
09:20:21 ns2. sshd[1325713]: fatal: Missing privilege separation
directory: /run/sshd

Diese Updates standen an:
ldap-utils libldap-2.5-0 libpam-systemd libsystemd0 libudev1 systemd
systemd-sysv tzdata udev

Cron meldde sich auch mit Problemen:
cron: can't lock /var/run/crond.pid, otherpid may be 421: Resource
temporarily unavailable

Systemd selbst auch:
systemd[1]: Failed to start Regular background program processing daemon.
systemd[1]: systemd-networkd.service: Got notification message from PID
288, but reception only permitted for main PID 1324417

Wie komme ich das repariert, neu installieren wollte ich erst mal nicht.

Tim

[Marcel Mueller]

Am 17.04.23 um 10:32 schrieb Tim Ritberg:

> Log sagt:
> Apr 17 09:14:20 ns2 systemd[1]: ssh.service: Found left-over process 970
> (sshd) in control group while starting unit. Ignoring.
> Apr 17 09:14:20 ns2 systemd[1]: This usually indicates unclean
> termination of a previous run, or service implementation deficiencies.
>
> Und weiter in rot:
> Apr 17 09:14:20 ns2 sshd[1324545]: error: Bind to port 22 on 0.0.0.0
> failed: Address already in use.
> Apr 17 09:14:20 ns2 sshd[1324545]: fatal: Cannot bind any address.

Ich würde sagen, entweder einer hat die Kiste (unprofessionell) gehackt
oder sshd läuft aus welchen Gründen auch immer zweimal.

> Systemd selbst auch:
> systemd[1]: Failed to start Regular background program processing daemon.
> systemd[1]: systemd-networkd.service: Got notification message from PID
> 288, but reception only permitted for main PID 1324417
>
> Wie komme ich das repariert, neu installieren wollte ich erst mal nicht.

Keine Ahnung. Um Ubuntu 22.04 mache ich aus verschiedenen Gründen einen
großzügigen Bogen.

Falls die Kiste echt nur DNS können soll, würde ich ein Debian Stable
nehmen und gar keine UI installieren. Das läuft Jahrzehnte, wenn man es
ließe.


Marcel

[Tim Ritberg]

Am 17.04.23 um 11:22 schrieb Marcel Mueller:

> Ich würde sagen, entweder einer hat die Kiste (unprofessionell) gehackt
> oder sshd läuft aus welchen Gründen auch immer zweimal.

Beides kann ich aussschließen, ausserdem kann wie man in Log sieht ssh
nicht 2x auf dem gleichen Socket laufen.

> Falls die Kiste echt nur DNS können soll, würde ich ein Debian Stable
> nehmen und gar keine UI installieren. Das läuft Jahrzehnte, wenn man es
> ließe.

Tut Ubuntu auch und wie kommst du darauf, dass ein Server eine (G)UI
haben müsste?


Tim

[Tim Ritberg]

Am 17.04.23 um 11:22 schrieb Marcel Mueller:

> Ich würde sagen, entweder einer hat die Kiste (unprofessionell)
>gehackt oder sshd läuft aus welchen Gründen auch immer zweimal.

Beides kann ich aussschließen, ausserdem kann wie man in Log sieht ssh
nicht 2x auf dem gleichen Socket laufen.

> Falls die Kiste echt nur DNS können soll, würde ich ein Debian Stable
>nehmen und gar keine UI installieren. Das läuft Jahrzehnte, wenn man
es >ließe.

Tut Ubuntu auch und wie kommst du darauf, dass ein Server eine (G)UI

haben könnte?


Tim

[Andreas Neumann]

Tim Ritberg wrote:

> Ach ja, Montag morgens Spass mit systemd.
>

> Systemd selbst auch:
> systemd[1]: Failed to start Regular background program processing daemon.
> systemd[1]: systemd-networkd.service: Got notification message from PID
> 288, but reception only permitted for main PID 1324417
>
> Wie komme ich das repariert, neu installieren wollte ich erst mal nicht.

Wieso, systemd-freie Distris existieren und funktionieren. Gut, dann hat man
halt leider nie wieder Spass damit... obwohl, systemd wollte mir trotz
Nichtvorhandensein mal in die Suppe spucken. Ließ sich aber mit kurzer
Recherche schmerzfrei umgehen.
Systemd funktioniert nach mehr als einem Jahrzehnt noch immer nicht
richtig... go figure. Wasser auf meine Mühlen.
Sorry, das wolltest Du nicht hören. Jedem soviel S&M wie er mag.

[Tim Ritberg]

Am 17.04.23 um 15:11 schrieb Andreas Neumann:

> Sorry, das wolltest Du nicht hören. Jedem soviel S&M wie er mag.Devuan ist jetzt nicht Thema ;-)
bzw hat der Hoster auch gar nicht zur Auswahl!

Tim

[Tim Ritberg]

Es hieß ja lange, man könnte systemd nur mit Reboot neustarten.
LP prouldy presents:
systemctl daemon-reexec

Und genau dann geht alles schief.
Mir ist das erst nicht aufgefallen, aber ein Versuch parallel noch mal
per ssh auf die Kiste zu gehen, ging schief.

Was ist sein Problem?

Tim

[Marcel Mueller]

Am 17.04.23 um 16:16 schrieb Tim Ritberg:

Möglicherweise gibt es Dienste, bei denen er den Status falsch rät. Das
kann dazu führen, dass Dienste doppelt gestartet werden. Solange systemd
selbst nicht neu gestartet wird, führt er den Status selbst unabhängig
von den laufenden Prozessen mit (und das ist bei einigen Diensten auch
Absicht, z.B. Typ oneshot). Startet man jetzt systemd neu, geht diese
Information aber verloren. Das ist daher keine gute Idee.


Marcel

[Tim Ritberg]

Am 17.04.23 um 20:40 schrieb Marcel Mueller:

Wie keine gute Idee? Das macht der Updater von Debian/Ubuntu.

Ich hab noch rausgefunden, dass /run/ssh fehlt. Das verschwindet irgendwie.

Tim

[Kay Martinen]

Am 17.04.23 um 15:44 schrieb Tim Ritberg:

> Am 17.04.23 um 15:11 schrieb Andreas Neumann:
>> Tim Ritberg wrote:
>>
>>> Ach ja, Montag morgens Spass mit systemd.
>>>
>>> Systemd selbst auch:
>>> systemd[1]: Failed to start Regular background program processing daemon.
>>> systemd[1]: systemd-networkd.service: Got notification message from PID
>>> 288, but reception only permitted for main PID 1324417
>>>
>>> Wie komme ich das repariert, neu installieren wollte ich erst mal nicht.
>>
>> Wieso, systemd-freie Distris existieren und funktionieren. Gut, dann hat man

>> Sorry, das wolltest Du nicht hören. Jedem soviel S&M wie er mag.Devuan ist jetzt nicht Thema ;-)
> bzw hat der Hoster auch gar nicht zur Auswahl!

Wechsele den Hoster oder mach es wieder On-Prem. Denn die Axt im EIGENEN
Hause... ;-)

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Friedemann Stoyan]

Tim Ritberg wrote:

> Ich hab noch rausgefunden, dass /run/ssh fehlt. Das verschwindet irgendwie.

Das wird vom systemd dynamisch angelegt durch:

[Service]
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

Entsteht beim Starten und verschwindet beim Stoppen.

mfg Friedemann

[Marc Haber]

Andreas Kohlbach <a...@spamfence.net> wrote:

>On Mon, 17 Apr 2023 11:22:05 +0200, Marcel Mueller wrote:
>> Ich würde sagen, entweder einer hat die Kiste (unprofessionell)
>> gehackt oder sshd läuft aus welchen Gründen auch immer zweimal.
>

>Mal
>
>nmap -p 22 localhost
>
>befragen.

Was erhoffst Du Dir davon?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marc Haber]

Tim Ritberg <t...@server.invalid> wrote:
>Es hieß ja lange, man könnte systemd nur mit Reboot neustarten.
>LP prouldy presents:
>systemctl daemon-reexec

Das ist so neu dass schon Debian buster und Ubuntu 2004 das können.

[Marc Haber]

Und das Verschwinden beim Stoppen ist manchmal das Problem, das
erlebte ich oft in Debian sid. Aber ich benutze sshd auch
socket-activated, deswegen habe ich da kein großes Fass draus gemacht.

|$ cat /etc/systemd/system/ssh@.service.d/runtime_directory_preserve.conf
|[Service]
|RuntimeDirectoryPreserve=yes

hat da geholfen.

[Tim Ritberg]

Am 18.04.23 um 07:47 schrieb Marc Haber:

> Tim Ritberg <t...@server.invalid> wrote:
>> Es hieß ja lange, man könnte systemd nur mit Reboot neustarten.
>> LP prouldy presents:
>> systemctl daemon-reexec
>
> Das ist so neu dass schon Debian buster und Ubuntu 2004 das können.
>

Kann schon sein. Nun macht es Probleme.

Tim

[Tim Ritberg]

Am 18.04.23 um 07:45 schrieb Marc Haber:

> Andreas Kohlbach <a...@spamfence.net> wrote:
>> On Mon, 17 Apr 2023 11:22:05 +0200, Marcel Mueller wrote:
>>> Ich würde sagen, entweder einer hat die Kiste (unprofessionell)
>>> gehackt oder sshd läuft aus welchen Gründen auch immer zweimal.
>>
>> Mal
>>
>> nmap -p 22 localhost
>>
>> befragen.
>
> Was erhoffst Du Dir davon?

Das frage ich mich auch. Vor allem wenn ich gar nicht auf die Kiste
drauf kann :-D

Tim

[Kay Martinen]

Am 18.04.23 um 08:59 schrieb Tim Ritberg:

Aber WENN du drauf wärest - könntest du deine eigene ssh session
aufzeichnen. :-)

Andreas hat vielleicht angenommen das <irgendwer> phyischen
konsolen-zugriff hätte. Wenn das bei $Hoster ein root-server wäre gäbe
es evtl. via IPMI, ILO o.a. konsolenzugriff. Bei shared oder v-server
zweifele ich ob das OoB machbar ist. InBand bestenfalls über die root-ip
der HW und einen ssh-zugang nur zu deinem System. Ob so was
machbar/angeboten wird???

Den Hoster scheint aber eh problematisch zu sein - bei systemd-freien
Alternativen...

[Tim Ritberg]

Am 18.04.23 um 09:57 schrieb Kay Martinen:

> Aber WENN du drauf wärest - könntest du deine eigene ssh session
> aufzeichnen. :-)

jajajajaja. Leider bieten nicht viele Hoster KVM oder
Xen-Virtualisierung an. Hoster mit Parallels haben keine Videoconsole.
Der andere DNS-Server steht bei Hetzner, da geht das.

> Den Hoster scheint aber eh problematisch zu sein - bei systemd-freien
> Alternativen...

Der andere Server mit bind und Ubuntu funktioniert ja.

Tim

[Arno Welzel]

Tim Ritberg, 2023-04-17 15:44:

> Am 17.04.23 um 15:11 schrieb Andreas Neumann:

[...]

>> Sorry, das wolltest Du nicht hören. Jedem soviel S&M wie er
>> mag.Devuan ist jetzt nicht Thema ;-)
> bzw hat der Hoster auch gar nicht zur Auswahl!

Es gibt Hoster, die erlauben einem, eigene Images zur Installation zu
verwenden, die man vorher selber hochladen kann.

--
Arno Welzel
https://arnowelzel.de

[Marc Haber]

Kay Martinen <use...@martinen.de> wrote:
>Am 18.04.23 um 08:59 schrieb Tim Ritberg:
>> Am 18.04.23 um 07:45 schrieb Marc Haber:
>>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>>> On Mon, 17 Apr 2023 11:22:05 +0200, Marcel Mueller wrote:
>>>>> Ich würde sagen, entweder einer hat die Kiste (unprofessionell)
>>>>> gehackt oder sshd läuft aus welchen Gründen auch immer zweimal.
>>>>
>>>> Mal
>>>>
>>>> nmap -p 22 localhost
>>>>
>>>> befragen.
>>>
>>> Was erhoffst Du Dir davon?
>> Das frage ich mich auch. Vor allem wenn ich gar nicht auf die Kiste
>> drauf kann :-D
>
>Aber WENN du drauf wärest - könntest du deine eigene ssh session
>aufzeichnen. :-)

Mit nmap?!?

>Andreas hat vielleicht angenommen das <irgendwer> phyischen
>konsolen-zugriff hätte. Wenn das bei $Hoster ein root-server wäre gäbe
>es evtl. via IPMI, ILO o.a. konsolenzugriff. Bei shared oder v-server
>zweifele ich ob das OoB machbar ist. InBand bestenfalls über die root-ip
>der HW und einen ssh-zugang nur zu deinem System. Ob so was
>machbar/angeboten wird???

Und was erfährt man von nmap gegen den eigenen Host?

[Kay Martinen]

Am 18.04.23 um 19:08 schrieb Marc Haber:

> Kay Martinen <use...@martinen.de> wrote:
>> Am 18.04.23 um 08:59 schrieb Tim Ritberg:
>>> Am 18.04.23 um 07:45 schrieb Marc Haber:
>>>> Andreas Kohlbach <a...@spamfence.net> wrote:

>>>>> Mal
>>>>> nmap -p 22 localhost
>>>>> befragen.
>>>>
>>>> Was erhoffst Du Dir davon?
>>> Das frage ich mich auch. Vor allem wenn ich gar nicht auf die Kiste
>>> drauf kann :-D
>>
>> Aber WENN du drauf wärest - könntest du deine eigene ssh session
>> aufzeichnen. :-)
>
> Mit nmap?!?

> Und was erfährt man von nmap gegen den eigenen Host?

UUuups. Nicht aufgepaßt. :-) Danke für den stupser.

[Tim Ritberg]

Am 19.04.23 um 02:16 schrieb Andreas Kohlbach:

> On Tue, 18 Apr 2023 07:45:41 +0200, Marc Haber wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>> On Mon, 17 Apr 2023 11:22:05 +0200, Marcel Mueller wrote:
>>>> Ich würde sagen, entweder einer hat die Kiste (unprofessionell)
>>>> gehackt oder sshd läuft aus welchen Gründen auch immer zweimal.
>>>
>>> Mal
>>>
>>> nmap -p 22 localhost
>>>
>>> befragen.
>>
>> Was erhoffst Du Dir davon?
>

> Damit erkennt er, ob schon etwas (meist der SSH) läuft, was an Port 22
> lauscht.
>
Das ist ja nicht alles, auch Cron spinnt rum.
Das geht grundsätzlich was schief.

Tim

[Marc Haber]

Andreas Kohlbach <a...@spamfence.net> wrote:
>On Tue, 18 Apr 2023 07:45:41 +0200, Marc Haber wrote:
>>

>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>>On Mon, 17 Apr 2023 11:22:05 +0200, Marcel Mueller wrote:
>>>> Ich würde sagen, entweder einer hat die Kiste (unprofessionell)
>>>> gehackt oder sshd läuft aus welchen Gründen auch immer zweimal.
>>>
>>>Mal
>>>
>>>nmap -p 22 localhost
>>>
>>>befragen.
>>
>> Was erhoffst Du Dir davon?
>

>Damit erkennt er, ob schon etwas (meist der SSH) läuft, was an Port 22
>lauscht.

Das ist aber eine Kanone auf einen Spatz, insbesondere wenn man root
auf dem betroffenen System ist.

[Tim Ritberg]

Am 18.04.23 um 07:50 schrieb Marc Haber:

> Friedemann Stoyan <use...@ip6-mail.de> wrote:
>> Tim Ritberg wrote:
>>
>>> Ich hab noch rausgefunden, dass /run/ssh fehlt. Das verschwindet irgendwie.
>>
>> Das wird vom systemd dynamisch angelegt durch:
>>
>> [Service]
>> RuntimeDirectory=sshd
>> RuntimeDirectoryMode=0755
>>
>> Entsteht beim Starten und verschwindet beim Stoppen.
>
> Und das Verschwinden beim Stoppen ist manchmal das Problem, das
> erlebte ich oft in Debian sid. Aber ich benutze sshd auch
> socket-activated, deswegen habe ich da kein großes Fass draus gemacht.
>
> |$ cat /etc/systemd/system/ssh@.service.d/runtime_directory_preserve.conf
> |[Service]
> |RuntimeDirectoryPreserve=yes
>
> hat da geholfen.
>
> Grüße
> Marc

Hier ist eine Beschreibung, die recht gut zu meinem Problem passt:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2013543

Tim

--
Xubuntu 22.10 64 bit, Kernel 5.19 (native)
ASRock x470 Taichi, 64 GB RAM, Ryzen 7 3700X

Eine Firewall ist kein Konzept! RTFM: RFC 2979