"wat er feitelijk gebeurt is dat het systeem ‘in het algemeen onstabiel aanvoelt’"

Dat gebeurt al op het moment dat je van sysv-init naar systemd overstapt!

systemd-notify [OPTIONS...] [VARIABLE=VALUE...]


sudo NOTIFY_SOCKET=/run/systemd/notify systemd-notify

Notify the init system about service status updates.

-h --help Show this help
--version Show package version
--ready Inform the init system about service start-up completion
--pid[=PID] Set main pid of daemon
--status=TEXT Set status text
--booted Check if the system was booted up with systemd

systemd 231 heeft er kennelijk geen last van omdat er een parameter meegegeven moet worden.

Copy/past is blijkbeet niet jullie sterkste kant?


Overigens gebeurt er dan niets.

Hier wel op een raspberry PI als NON root:

Broadcast message from systemd-journald@hostname (Tue 2016-10-04 17:48:52 CEST):

systemd[1]: Caught <ABRT>, dumped core as pid 1769.


Message from syslogd@hostname at Oct 4 17:48:52 ...
systemd[1]: Freezing execution.

Broadcast message from systemd-journald@hostname (Tue 2016-10-04 17:48:52 CEST):

systemd[1]: Freezing execution.

Oh, wat leuk. Zal het eens proberen. Grappig dat je met zo'n code je Linux-installatie net zo laat aanvoelen als Windows. :)

Een Pi met raspbian (systemd 215) geen probleem, een Pi met Kali (systemd 231) 'crashed' zoals hierboven ook al te zien is.

Vroeger had je in Windows ook /con/con om je PC te laten crashen ;-)

Is een hdd erase commando in disk utility niet korter en gevaarlijker?

Er zijn veel commando's die je systeem kunnen laten crashen, het bekendste voorbeeld is wel format c:/

Te laat! De mijne hobbelt gewoon verder

Het verschil is dat je voor een hdd erase commando gewoonlijk maximale privileges nodig hebt (genoeg om op tig andere manieren een systeem te kunnen crashen), en het laten hangen van systemd als reguliere user kon.

De 'slechts 48 bytes' claim is niet het bijzondere, dat is 'gewone user laat systeem hangen'

Verrek, je zegt het. Bij mij start die dan helemaal niet meer op!!!!

Aha, als je vroeger een file genaamd "-rf" aanmaakte, en dan typte "rm *" in die directory, ideale test of je backups goed waren!

Voorlopig draaien mijn servers nog op Debian Wheezy. Dat is gelukkig nog zonder systemd. Jessie is ook mogelijk zonder systemd. Ik zou het niet op mijn servers willen hebben.

RHEL 7, systemd 219 geen probleem.

Dus, als je,als root, een commando intikt kan je een linux systeem laten 'crashen' . wouw... I'm impressed...

Als je niet kunt lezen reageer dan ook niet.

Het is als normale user ZONDER extra rechten uitvoerbaar.

LinuxPro .....

Allemaal weer lichtelijk overdreven. Wat er gebeurt is dat het init systeem hangt zodat er bijvoorbeeld geen nieuwe services gestart kunnen worden en bepaalde beheertaken niet meer (goed) kunnen worden uitgevoerd. Afhankelijk van de mate van initialisatie en implementatie van systemd-onderdelen zullen bijvoorbeeld het Inloggen en het wisselen naar VT's niet meer werken.

Kortom Linux crasht niet en de gebruiker kan de desktop blijven gebruiken zonder al te veel problemen. De kans is groot dat er na een tijdje problemen ontstaan doordat geplande services niet meer draaien en processen problemen ondervinden omdat het init systeem niet reageert. Ook is veilig afsluiten niet meer mogelijk.

Het is zeker iets dat niet mogelijk zou moeten zijn, maar het besturingssysteem loopt niet vast, enkel het init systeem loopt vast (wat overigens wel grote gevolgen kan hebben doordat systemd een zeer uitgebreid init systeem is). Hopelijk zorgt dit voor betere QA en een meer modulair systeem zodat de impact verkleind kan worden.

Gisteren uitgevoerd op Debian stable. Op het moment zelf gebeurde er niets, na 'sudo poweroff' bleef Debian hangen tijdens het afsluiten.
Nee, niet als root, als gewone user.

Het was te vroeg.. niet goed gelezen.. excuus ;-)

Dus... als de IoT camera's uit dat grote botnet van afgelopen week hier gevoelig voor zijn, dan kunnen we hiermee het botnet langzaam om zeep helpen. Tijd voor een tegenbot? Klein beetje de C code aanpassen en software-roulette op andermans IoT device draaien...

Je kan ook 'reboot' intikken of 'kill -9 0' wat je ook kan doen is op de uit knop drukken en buiten gaan spelen, next...

Als je de code doorgelezen had, had je gezien dat als de bot een busybox krijgt, een van de dingen die het gelijk doet is alle processen afschieten die op poort 80 22 en 23 luisteren. Dit om herinfectie door de concurent te voorkomen en de eigenaar buiten te sluiten. ik denk niet dat je tegenbot dan gaat werken.

Wat blijft lezen toch een lastig iets, begrijpend lezen al helemaal.

Je hebt als normale user helemaal geen rechten om een Linux systeem te rebooten op welke manier dan ook.

Yes say that well!
Misschien een idee om niet 1 uitgebreid init systeem te maken maar een veel simpeler systeem wat niet probeert
alles te regelen in 1 enkele omgeving?
Zeg maar, hoe het werkte voor dit onzalige ding werd uitgevonden?

Dat is waar, maar dan installeren we 'polkit' om ons leven makelijker te maken, voila, user rechten om te rebooten.

Interessante bewering : met welke code van 48 karakters kan je een Windows installatie met gewone user laten crashen?

Niet grappig. Werk inderdaad goed als aangegeven.

OS Debian jessie amd64.

Vanuit console run dit command:
NOTIFY_SOCKET=/run/systemd/notify systemd-notify

Dan even wachten...

Stukje uit log:
[Thu Oct 6 11:13:19 2016] systemd-journald[160]: Received SIGTERM from PID 1 (systemd).
[Thu Oct 6 11:13:19 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:13:20 2016] systemd-journald[1126]: Received request to flush runtime journal from PID 1
[Thu Oct 6 11:14:26 2016] systemd[1]: systemd-logind.service watchdog timeout (limit 1min)!
[Thu Oct 6 11:14:26 2016] systemd[1]: Unit systemd-logind.service entered failed state.
[Thu Oct 6 11:15:50 2016] systemd[1]: systemd-journald.service stop-sigterm timed out. Killing.
[Thu Oct 6 11:15:50 2016] systemd[1]: systemd-journald.service: main process exited, code=killed, status=9/KILL
[Thu Oct 6 11:15:50 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:16:50 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:27 2016] systemd[1]: Unit systemd-logind.service entered failed state.
[Thu Oct 6 11:17:50 2016] systemd[1]: systemd-journald.service watchdog timeout (limit 1min)!
[Thu Oct 6 11:17:50 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: systemd-journald.service start request repeated too quickly, refusing to start.
[Thu Oct 6 11:17:51 2016] systemd[1]: Failed to start Journal Service.
[Thu Oct 6 11:17:51 2016] systemd[1]: Dependency failed for Trigger Flushing of Journal to Persistent Storage.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: systemd-journald.service start request repeated too quickly, refusing to start.
[Thu Oct 6 11:17:51 2016] systemd[1]: Failed to start Journal Service.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.socket entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald-dev-log.socket entered failed state.

Alleen mijn systeem gaat niet plat. ik kan nog steeds via ssh inloggen op het systeem via het netwerk.

Commando:

$ NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

systemd gaat naar een zogenaamde degraded status.

Na een kwartier:
$ systemctl status

gefliptehost
State: degraded
Jobs: 1 queued
Failed: 3 units
Since: Thu 2016-10-06 11:00:18 CEST; 24min ago
CGroup: /
??1 /sbin/init
??system.slice
? ??avahi-daemon.service
? ? ??438 avahi-daemon: running [africa.local
? ? ??487 avahi-daemon: chroot helpe
? ??dbus.service
? ? ??440 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
? ??ModemManager.service
? ? ??426 /usr/sbin/ModemManager
? ??cron.service
? ? ??425 /usr/sbin/cron -f
? ??nfs-common.service
? ? ??409 /sbin/rpc.statd
? ? ??423 /usr/sbin/rpc.idmapd
? ??exim4.service
? ? ??725 /usr/sbin/exim4 -bd -q30m
? ??lightdm.service
? ? ??706 /usr/sbin/lightdm
? ? ??730 /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
? ? ??848 lightdm --session-child 13 20
? ??atd.service
? ? ??428 /usr/sbin/atd -f
? ??minissdpd.service
? ? ??454 /usr/sbin/minissdpd -i 0.0.0.0
? ??cups.service
? ? ??698 /usr/sbin/cupsd -f
? ??ssh.service
? ? ?? 429 /usr/sbin/sshd -D
? ? ??1249 sshd: student [priv]
? ? ??1255 sshd: student@pts/1
? ? ??1256 -bash
? ? ??1267 systemctl status
? ? ??1268 pager
? ??systemd-logind.service
? ? ??1254 /lib/systemd/systemd-logind
? ??systemd-udevd.service
? ? ??168 /lib/systemd/systemd-udevd
? ??polkitd.service
? ? ??702 /usr/lib/policykit-1/polkitd --no-debug
? ??rpcbind.service
? ? ??400 /sbin/rpcbind -w
? ??cups-browsed.service
? ? ??699 /usr/sbin/cups-browsed
? ??NetworkManager.service
? ? ??431 /usr/sbin/NetworkManager --no-daemon
? ? ??748 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /var/run/dhclient-eth0.pid -lf /var/lib/Network
? ??rsyslog.service
? ? ??696 /usr/sbin/rsyslogd -n
? ??acpid.service
? ??697 /usr/sbin/acpid
??user.slice
??user-1000.slice
? ??session-1.scope
? ? ??704 /bin/login --
? ? ??855 -bash
? ??user@1000.service
? ? ??852 /lib/systemd/systemd --user
? ? ??853 (sd-pam)
? ??session-2.scope
? ??1109 sshd: student [priv]
? ??1111 sshd: student@pts/0
? ??1112 -bash
??user-117.slice
??user@117.service
? ??827 /lib/systemd/systemd --user
? ??828 (sd-pam)
??session-c1.scope
??824 lightdm --session-child 17 20
??830 /usr/sbin/lightdm-gtk-greeter
??835 /usr/bin/dbus-launch --autolaunch 09ea9df544e6b54e8d9a8abf2fae69d1 --binary-syntax --close-stderr
??836 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
??838 /usr/lib/at-spi2-core/at-spi-bus-launcher
??842 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
??845 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session

Trek het systeem weer vlot:

#Ga na wat er aan de hand is

$ sudo systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
? systemd-journald.service loaded failed failed Journal Service
? systemd-journald-dev-log.socket loaded failed failed Journal Socket (/dev/log)
? systemd-journald.socket loaded failed failed Journal Socket

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
student@africa:~$ systemctl reset-failed
Failed to execute operation: Access denied

#Maak failed services weer actief
$ systemctl status systemd-journald.service
? systemd-journald.service - Journal Service
Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
Active: inactive (dead) since Thu 2016-10-06 11:17:51 CEST; 31min ago
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 1203 (code=killed, signal=USR1

$ sudo systemctl start systemd-journald.service
$ systemctl status systemd-journald.service
? systemd-journald.service - Journal Service
Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
Active: active (running) since Thu 2016-10-06 11:49:59 CEST; 1s ago
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 1541 (systemd-journal)
Status: "Processing requests..."
CGroup: /system.slice/systemd-journald.service
??1541 /lib/systemd/systemd-journald

#Doe dit voor alle "failed" services

# Maak schoon
$ sudo systemctl reset-failed

Veel plezier.

Detail: het systeem ging nooit plat. Kon het gewoon remote beheren. En de log geeft het euvel mooi weer, dus je kan nagaan wat er aan hand was.
Jammer is wel dat een willekeurige gebruiken met beperkte rechten het systeem in een minder leuke staat kan zetten door een simpel commando uit te voeren.

Jammer genoeg lijken dit soort incidenten nodig om de ogen te openen van de grote distributies. Het kalf moet eerst verdrinken, zeg maar.

Voor degene die op safe willen spelen, enkele Linux distributies die niet vatbaar zijn:
- Slackware
- Gentoo (tenzij bewust voor Systemd is gekozen)
- Void
- Debian Jessie (systemd kan eenvoudig verwijderd worden)
- Devuan (nieuwe distributie van een Nederlandse stichting. Systemd-loze Debian fork)

Is dus ook niet echt een Linux probleem, dus vind het netjes dat de kop van het artikel "systemd" noemt.

Vroeger update ik mijn BIOS door met een schroevendraaier de BIOS rom van het moederbord te wippen, de pootjes van de nieuwe BIOS recht te buigen en in de lege DIL-socket te duwen. Ging dit mis dan kon je altijd nog de oude BIOS terug zetten (als de pootje rechts stonden) Bij het inbouwen van een nieuwe MFM schijf van 10 MB even met DEBUG de bad-sector table invoeren.....


Maar vroeger is vroeger , het is nu wat geld.

Vroeger had ik ook een UNIX mini staan die met een rs232 verbinding naar mijn VT100 emulatie ging, ja vroeger ;-)