Fehlermeldungen im init system

[niesommer]

Hallo,
Nun da mein account nicht gelöscht wurde, möchte ich euch um rat fragen.
Auf der suche nach einer deutschsprachigen doku dazu bin ich nicht fündig geworden, was es dazu gibt ist sehr sehr oberflächlich wie: http://manual.siduction.org/sys-admin-systemd#systemd
https://wiki.archlinux.de/title/Systemd
und verschiedene andere Seiten, die mich nicht weiter brachten. Ich verwende derzeit Debian Jessie.
Zum Problem:

Code: Alles auswählen

journalctl -b -p err

Ausgabe:

Code: Alles auswählen

Mai 06 10:55:02 tbbt wdm[1843]: 
Mai 06 10:55:02 tbbt wdm[1843]: X.Org X Server 1.16.4
Mai 06 10:55:02 tbbt wdm[1843]: Release Date: 2014-12-20
Mai 06 10:55:02 tbbt wdm[1843]: X Protocol Version 11, Revision 0
Mai 06 10:55:02 tbbt wdm[1843]: Build Operating System: Linux 3.2.0-4-amd64 i686 Debian
Mai 06 10:55:02 tbbt wdm[1843]: Current Operating System: Linux tbbt 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) i686
Mai 06 10:55:02 tbbt wdm[1843]: Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-686-pae root=/dev/mapper/tbbt-root ro quiet ipv6.disable=1
Mai 06 10:55:02 tbbt wdm[1843]: Build Date: 11 February 2015  01:14:26AM
Mai 06 10:55:02 tbbt wdm[1843]: xorg-server 2:1.16.4-1 (http://www.debian.org/support)
Mai 06 10:55:02 tbbt wdm[1843]: Current version of pixman: 0.32.6
Mai 06 10:55:02 tbbt wdm[1843]: Before reporting problems, check http://wiki.x.org
Mai 06 10:55:02 tbbt wdm[1843]: to make sure that you have the latest version.
Mai 06 10:55:02 tbbt wdm[1843]: Markers: (--) probed, (**) from config file, (==) default setting,
Mai 06 10:55:02 tbbt wdm[1843]: (++) from command line, (!!) notice, (II) informational,
Mai 06 10:55:02 tbbt wdm[1843]: (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
Mai 06 10:55:02 tbbt wdm[1843]: (==) Log file: "/var/log/Xorg.0.log", Time: Wed May  6 10:55:02 2015
Mai 06 10:55:02 tbbt wdm[1843]: (==) Using config directory: "/etc/X11/xorg.conf.d"
Mai 06 10:55:02 tbbt wdm[1843]: (==) Using system config directory "/usr/share/X11/xorg.conf.d"
Mai 06 10:55:04 tbbt wdm[1843]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Mai 06 10:55:04 tbbt wdm[1843]: > Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
Mai 06 10:55:04 tbbt wdm[1843]: >                   Ignoring extra symbols
Mai 06 10:55:04 tbbt wdm[1843]: Errors from xkbcomp are not fatal to the X server
Mai 06 10:55:05 tbbt wdm[1843]: Cannot open config file. Using builtin defaults
Mai 06 11:00:44 tbbt kernel: CPU0: Core temperature above threshold, cpu clock throttled (total events = 1)
Mai 06 11:00:44 tbbt kernel: CPU0: Package temperature above threshold, cpu clock throttled (total events = 1)
Mai 06 11:00:45 tbbt kernel: CPU1: Package temperature above threshold, cpu clock throttled (total events = 1)
Mai 06 11:10:44 tbbt kernel: CPU0: Package temperature above threshold, cpu clock throttled (total events = 78469)
Mai 06 11:10:44 tbbt kernel: CPU1: Package temperature above threshold, cpu clock throttled (total events = 78469)
Mai 06 15:12:44 tbbt systemd[1]: Failed to start Run anacron jobs.

Die Ausgabe habe ich um die Redundanzen gekürzt.
Das brachte mich dazu nachforschungen anzustellen, dabei bi ich auf folgende sachen gestossen:

Code: Alles auswählen

 systemctl --all > alles.txt

pastebin.php?mode=view&s=38502
Also alles in allem sind hier einige Sachen die nicht richtig funktionieren. Mein drängendes Problem ist das nicht funktionieren von anacron. Aber natürlich würde ich gern auch alle anderen fehler beseitigen.

Hier wird https://www.debian.org/releases/jessie/ ... idp1029168 darauf verwiesen das es probleme zwischen ACPID und logind geben könnte, ich habe mich entshieden erst einmal entsprechende sachen in der logind.conf auszukommentieren. Ich habe die Laptop-mode tools in betrieb, die ich mit hilfe des forums damals ans laufen brachte, und die Einstellungen möchte ich nicht verlieren, allerdings scheitere ich auch hier auf grund mangelnder deutschsprachiger dokumentationen zu diesem systemd zeugs und weiß nicht wie ich das umsetzen kann.

Hoffe das ihr mir weiterhelfen könnt.

Nachtrag: Der schalter -x brachte noch weitere informationen:

Code: Alles auswählen

 journalctl -b -p err -x

Code: Alles auswählen

-- Subject: Unit anacron.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit anacron.service has failed.
-- 
-- The result is failed.
Mai 06 15:12:45 tbbt systemd[1]: Failed to start Run anacron jobs.
-- Subject: Unit anacron.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit anacron.service has failed.
-- 
-- The result is failed.
Mai 06 15:12:45 tbbt systemd[1]: Failed to start Run anacron jobs.
-- Subject: Unit anacron.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit anacron.service has failed.
-- 
-- The result is failed.

[smutbert]

Also das was dein Displaymanager (wdm) von sich gibt sind keine Fehlermeldungen, sondern ganz normale Statusmeldungen von und harmlose Warnungen von xorg. Daran dass journalctl sie trotzdem ausgibt würde ich am ehesten wdm die Schuld geben.

Die Zeilen mit den Kernelmeldungen sind wahrscheinlich eh klar: Die weisen darauf hin, dass die CPU so heiß wurde, dass sie gedrosselt wurde.

Bei der Sache mit anacron kann ich dir nicht weiterhelfen, fürchte ich.

Zu den laptop-mode-tools: Worum ist es denn da gegangen, dass du etwas konfigurieren musstest? (ich würde am ehesten versuchen das was du haben willst mit systemd/logind zu erreichen - alles andere wäre in Zukunft wahrscheinlich immer schwieriger beizubehalten)

Bleibt noch die Ausgabe von systemctl. Geht es dir da um etwas bestimmtes?
Mir stechen zB einige not-found Einträge ins Auge, wie zB mysql. Könnte es sein, dass du mysql installiert hattest, es aber wieder exklusive der Konfigurationsdateien deinstalliert hast? Dann wäre das initskript zwar noch vorhanden, aber es gäbe nichts mehr, was es starten könnte.
Was sagt denn

Code: Alles auswählen

$ dpkg -l mysql*

[JTH]

Mein drängendes Problem ist das nicht funktionieren von anacron.

Das Problem mit anacron war mir vor ein paar Monaten auch mal aufgefallen. Ich hab dann systemd-cron ausprobiert (ersetzt die Pakete cron und anacron). Das funktioniert bisher problemlos. Ob anacron im Zusammenspiel mit systemd überhaupt funktioniert, habe ich damals nicht weiter recherchiert.

[maledora4]

Code: Alles auswählen

systemctl --state=failed

oder

Code: Alles auswählen

systemctl list-unit-files | grep failed

sollten schon weiterhelfen und

Code: Alles auswählen

systemctl status anacron.service

bitte hier zeigen.

[NAB]

Zu anacron gibt es diesen Release-Critical Bug, der unfreundlicher Weise ignoriert wurde:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=744753

Kurz gesagt kriegt systemd es nicht gebacken, anacron nach einem Suspend wieder zu starten.

hdparm hat ähnliche Probleme ... dagegen hilft vermutlich, sysvinit-core zu installieren ...

Den Hinweis von JTH würde ich aber vorher ausprobieren.

[niesommer]

Also das was dein Displaymanager (wdm) von sich gibt sind keine Fehlermeldungen, sondern ganz normale Statusmeldungen von und harmlose Warnungen von xorg. Daran dass journalctl sie trotzdem ausgibt würde ich am ehesten wdm die Schuld geben.

Es geht ja nicht darum wer woran schuld hat, sondern um ein ordnungsgemäßes funktionieren des systems ist ja schließlich ein stable.

Die Zeilen mit den Kernelmeldungen sind wahrscheinlich eh klar: Die weisen darauf hin, dass die CPU so heiß wurde, dass sie gedrosselt wurde.

Stellt sich die frage wie so die CPU zu heiß wird?

Zu den laptop-mode-tools: Worum ist es denn da gegangen, dass du etwas konfigurieren musstest? (ich würde am ehesten versuchen das was du haben willst mit systemd/logind zu erreichen - alles andere wäre in Zukunft wahrscheinlich immer schwieriger beizubehalten)

Weiß ich nicht mehr genau, aber habe dazu noch das hier gefunden was ich damals gemacht habe:
viewtopic.php?f=26&t=140936&hilit=niesommer%23
Ich würde Logind dafür gerne benutzen nur weiß ich eben nicht wie, keine deutsche doku.

Bleibt noch die Ausgabe von systemctl. Geht es dir da um etwas bestimmtes?
Mir stechen zB einige not-found Einträge ins Auge, wie zB mysql. Könnte es sein, dass du mysql installiert hattest, es aber wieder exklusive der Konfigurationsdateien deinstalliert hast? Dann wäre das initskript zwar noch vorhanden, aber es gäbe nichts mehr, was es starten könnte.
Was sagt denn

Code: Alles auswählen

$ dpkg -l mysql*

Code: Alles auswählen

dpkg -l mysql*
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                                            Version                      Architektur                  Beschreibung
+++-===============================================-============================-============================-===================================================================================================
un  mysql-client-5.1                                <keine>                      <keine>                      (keine Beschreibung vorhanden)
ii  mysql-common                                    5.5.43-0+deb8u1              all                          MySQL database common files, e.g. /etc/mysql/my.cnf
un  mysql-server-5.1                                <keine>                      <keine>                      (keine Beschreibung vorhanden)
un  mysql-server-core-5.1                           <keine>                      <keine>                      (keine Beschreibung vorhanden)

PS: Ich antworte noch auf die anderen Beiträge, bitte daher um etwas Geduld danke.

[niesommer]

Mein drängendes Problem ist das nicht funktionieren von anacron.

Das Problem mit anacron war mir vor ein paar Monaten auch mal aufgefallen. Ich hab dann systemd-cron ausprobiert (ersetzt die Pakete cron und anacron). Das funktioniert bisher problemlos. Ob anacron im Zusammenspiel mit systemd überhaupt funktioniert, habe ich damals nicht weiter recherchiert.

OK, werde ich ausprobieren, und melde mich später nochmal.

[niesommer]

Code: Alles auswählen

systemctl --state=failed

Ausgabe:

Code: Alles auswählen

systemctl --state=failed
  UNIT            LOAD   ACTIVE SUB    DESCRIPTION
● anacron.service loaded failed failed Run anacron jobs

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.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

oder

Code: Alles auswählen

systemctl list-unit-files | grep failed

Gibt nichts aus.

Code: Alles auswählen

systemctl status anacron.service

bitte hier zeigen.

Ausgabe:

Code: Alles auswählen

 systemctl status anacron.service
● anacron.service - Run anacron jobs
   Loaded: loaded (/lib/systemd/system/anacron.service; enabled)
   Active: failed (Result: start-limit) since Mi 2015-05-06 17:44:52 CEST; 33min ago
  Process: 4642 ExecStart=/usr/sbin/anacron -dsq (code=exited, status=0/SUCCESS)
 Main PID: 4642 (code=exited, status=0/SUCCESS)

Mai 06 17:44:52 tbbt anacron[4642]: Anacron 2.3 started on 2015-05-06
Mai 06 17:44:52 tbbt systemd[1]: anacron.service start request repeated too quickly, refusing to start.
Mai 06 17:44:52 tbbt systemd[1]: Failed to start Run anacron jobs.
Mai 06 17:44:52 tbbt systemd[1]: Unit anacron.service entered failed state.
Mai 06 17:44:52 tbbt systemd[1]: anacron.service start request repeated too quickly, refusing to start.
Mai 06 17:44:52 tbbt systemd[1]: Failed to start Run anacron jobs.
Mai 06 17:44:52 tbbt systemd[1]: anacron.service start request repeated too quickly, refusing to start.
Mai 06 17:44:52 tbbt systemd[1]: Failed to start Run anacron jobs.

[niesommer]

Zu anacron gibt es diesen Release-Critical Bug, der unfreundlicher Weise ignoriert wurde:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=744753

Kurz gesagt kriegt systemd es nicht gebacken, anacron nach einem Suspend wieder zu starten. .

Das ist sehr unschön und entspricht so langsam meinen Erwartungen, ich frage mich nur was sowas in einem stable-system zu suchen hat.

hdparm hat ähnliche Probleme ... dagegen hilft vermutlich, sysvinit-core zu installieren ...

Den Hinweis von JTH würde ich aber vorher ausprobieren.

Nun ich hatte schon eine Fehlermeldung weil hdparm gefehlt hat, ich hatte es nicht installiert nach dem ich es installiert habe verschwandt der Fehler.
So werde jetzt mal den Tip von JTH ausprobieren, mal sehen was es bringt.

[NAB]

Das ist sehr unschön und entspricht so langsam meinen Erwartungen, ich frage mich nur was sowas in einem stable-system zu suchen hat.

Ich will ja keine alten Diskussionen wieder aufwärmen, aber bei dem jetztigen Zustand von Systemd in Debian habe ich den Eindruck, der einzige Zweck von Systemd ist es, Probleme zu analysieren, die man ohne Systemd gar nicht hätte ...

Nach meinen bisherigen Tests kann man recht problemlos zwischen sysvinit-core und systemd-sysv hin- und herspringen ... das wäre die einfachste Methode, die gewohnte Funktionalität wiederzuerlangen. Andererseits wird es auch nicht schaden, wenn du dich etwas mit Systemd auseinandersetzt und den Hinweisen von JTH folgst ... bei Debian Stretch wird es zukünftig nicht mehr anders gehen.

[JTH]

[…] und den Hinweisen von JTH folgst ...

Das ist generell immer eine gute Idee!

[niesommer]

Ich will ja keine alten Diskussionen wieder aufwärmen, aber bei dem jetztigen Zustand von Systemd in Debian habe ich den Eindruck, der einzige Zweck von Systemd ist es, Probleme zu analysieren, die man ohne Systemd gar nicht hätte ...

Darin stimmen wir überein, und ich möchte diese Diskussionen auch nicht wieder aufwärmen. Denn jetzt ist es da und man muss damit zurecht kommen. Das einzige was ich dazu anmerken möchte ist: Soviel zu Vereinfachung Verbesserung usw. kein Wunder das es schneller bootet was vielen wichtiger zu sein scheint als Funktion.

Nach meinen bisherigen Tests kann man recht problemlos zwischen sysvinit-core und systemd-sysv hin- und herspringen ... das wäre die einfachste Methode, die gewohnte Funktionalität wiederzuerlangen. Andererseits wird es auch nicht schaden, wenn du dich etwas mit Systemd auseinandersetzt und den Hinweisen von JTH folgst ... bei Debian Stretch wird es zukünftig nicht mehr anders gehen.

Von diesen hin und herschalten halte ich noch nicht allzuviel, von daher ist das im moment keine Option für mich.
Die Auseinandersetzung mit systemd wird zu einem Problem für mich denn es gibt keine deutschsprachige dokumentation, die manualpages (man) sind soweit ich gesehen habe d.h. die die ich mir angesehen habe sind alle in englisch und für mich nicht verständlich.

[…] und den Hinweisen von JTH folgst ...

Das ist generell immer eine gute Idee!

So ich habe deinen Tip umgesetzt, allerdings fällt es mir schwer heraus zu bekommen, welches ergebniss jetzt vorliegt.
Rechner neugestartet!
Befehl und Ausgabe:

Code: Alles auswählen

systemctl status anacron.service
● anacron.service
   Loaded: masked (/dev/null)
   Active: inactive (dead)

Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.

Nach ausführen von: systemctl daemon-reload

Code: Alles auswählen

systemctl status anacron.service
● anacron.service
   Loaded: masked (/dev/null)
   Active: inactive (dead)

Da ich den Rechner zwischen durch ausgeschaltet habe und ihn neugestartet habe, bedeutet das ergebnis das es immer noch nicht richtig funktioniert und ich nach jedem rechner einschalten erst einmal diesen Befehl : systemctl daemon-reload ausführen muss.
Sehr unbefriedigend!
Dieser Befehl:

Code: Alles auswählen

 journalctl -b -p err

gibt jetzt nur noch den Block mit dem WDM aus. Das stimmt mich wieder etwas milde.
Aber dennoch scheint es einen sehr unfertigen und instabilen eindruck zu machen. Na mal sehen was da noch so kommt.
Danke schon mal an alle Tip geber bzw. helfer.

[KP97]

@niesommer
Du weißt, daß anacron nur einmal am am Tag läuft? Der Start wird ja über das Systemdatum abgefragt. Wenn also beim ersten Einschalten am Tag der Job gestartet wird, nutzt ein mehrfaches Neustarten gar nichts. Anacron hat seine Aufgabe erledigt und schweigt still bis zum nächsten Tag. Wenn Jobs mehrfach und zu bestimmten Uhrzeiten laufen sollen, ist Cron die richtige Wahl.
Mein anacron läuft, aber ich habe auch ein Sid:

systemctl status anacron.service
● anacron.service - Run anacron jobs
Loaded: loaded (/lib/systemd/system/anacron.service; enabled)
Active: inactive (dead) since Mi 2015-05-06 16:53:15 CEST; 3h 12min ago
Main PID: 2882 (code=exited, status=0/SUCCESS)
Mai 06 16:47:56 SID anacron[2882]: Anacron 2.3 started on 2015-05-06
Mai 06 16:47:56 SID anacron[2882]: Will run job `cron.daily' in 5 min.
Mai 06 16:47:56 SID anacron[2882]: Jobs will be executed sequentially
Mai 06 16:52:56 SID anacron[2882]: Job `cron.daily' started
Mai 06 16:52:56 SID su[6738]: Successful su for nobody by root
Mai 06 16:52:56 SID su[6738]: pam_unix(su:session): session opened for user nobody by (uid=0)
Mai 06 16:52:56 SID su[6738]: pam_unix(su:session): session closed for user nobody
Mai 06 16:52:56 SID su[6754]: Successful su for nobody by root
Mai 06 16:52:56 SID su[6754]: pam_unix(su:session): session opened for user nobody by (uid=0)
Mai 06 16:52:56 SID su[6754]: pam_unix(su:session): session closed for user nobody
Mai 06 16:52:56 SID su[6770]: Successful su for nobody by root
Mai 06 16:52:56 SID su[6770]: pam_unix(su:session): session opened for user nobody by (uid=0)
Mai 06 16:53:15 SID su[6770]: pam_unix(su:session): session closed for user nobody

Aber noch sind ja die Versionen von systemd in Jessie und Sid die gleichen, daran kann es also nicht liegen.

[JTH]

Einen richtigen cron- bzw. anacron-Dienst gibt es bei dir nach der Installation von systemd-cron nicht mehr, deshalb gibt dir systemctl auch keinen Status dazu aus. Das Paket baut die Funktionsweise von (ana)cron mit ein paar systemd-Timer-Beschreibungen nach:

Code: Alles auswählen

$ dpkg -L systemd-cron | grep timer
/lib/systemd/system/cron-monthly.timer
/lib/systemd/system/cron-daily.timer
/lib/systemd/system/cron-weekly.timer
/lib/systemd/system/cron-hourly.timer

Timer sind ein Feature von systemd – eins der vielen, die bestehende Lösungen ersetzen wollen – mit dem man Dienste und anderes wie mit cron zu bestimmten Zeitpunkten ausführen kann. Prinzipiell ist es so gedacht, dass man dies „nativ“ für systemd mit .timer-Dateien konfiguriert (man systemd.timer), mit dem Paket oben kann man aber auch die cron-Konfiguration (vorerst (?)) weiter verwenden.

Du kannst dir anscheinend Logs der einzelnen Timer angucken (aus man systemd.cron):

Code: Alles auswählen

# journalctl -u cron-boot
# journalctl -u cron-hourly
# journalctl -u cron-daily
# journalctl -u cron-weekly
# journalctl -u cron-monthly
# journalctl -u cron-yearly

Da steht allerdings (bei mir zumindest) nicht viel drin.

Und auch den Zeitpunkt, wann sie das nächste Mal ausgeführt werden:

Code: Alles auswählen

$ systemctl list-timers

Code: Alles auswählen

systemctl status anacron.service
● anacron.service
   Loaded: masked (/dev/null)
   Active: inactive (dead)

Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.

anacron.service scheint bei dir noch mit einem Link /etc/systemd/system/anacron.service -> /dev/null maskiert zu sein. Den könntest du entfernen, er stört aber auch nicht.

[niesommer]

@niesommer
Du weißt, daß anacron nur einmal am am Tag läuft?

JA, das habe ich auch so verstanden.

Der Start wird ja über das Systemdatum abgefragt. Wenn also beim ersten Einschalten am Tag der Job gestartet wird, nutzt ein mehrfaches Neustarten gar nichts. Anacron hat seine Aufgabe erledigt und schweigt still bis zum nächsten Tag. Wenn Jobs mehrfach und zu bestimmten Uhrzeiten laufen sollen, ist Cron die richtige Wahl.
Mein anacron läuft, aber ich habe auch ein Sid:

systemctl status anacron.service
● anacron.service - Run anacron jobs
Loaded: loaded (/lib/systemd/system/anacron.service; enabled)
Active: inactive (dead) since Mi 2015-05-06 16:53:15 CEST; 3h 12min ago
Main PID: 2882 (code=exited, status=0/SUCCESS)
Mai 06 16:47:56 SID anacron[2882]: Anacron 2.3 started on 2015-05-06
Mai 06 16:47:56 SID anacron[2882]: Will run job `cron.daily' in 5 min.
Mai 06 16:47:56 SID anacron[2882]: Jobs will be executed sequentially
Mai 06 16:52:56 SID anacron[2882]: Job `cron.daily' started
Mai 06 16:52:56 SID su[6738]: Successful su for nobody by root
Mai 06 16:52:56 SID su[6738]: pam_unix(su:session): session opened for user nobody by (uid=0)
Mai 06 16:52:56 SID su[6738]: pam_unix(su:session): session closed for user nobody
Mai 06 16:52:56 SID su[6754]: Successful su for nobody by root
Mai 06 16:52:56 SID su[6754]: pam_unix(su:session): session opened for user nobody by (uid=0)
Mai 06 16:52:56 SID su[6754]: pam_unix(su:session): session closed for user nobody
Mai 06 16:52:56 SID su[6770]: Successful su for nobody by root
Mai 06 16:52:56 SID su[6770]: pam_unix(su:session): session opened for user nobody by (uid=0)
Mai 06 16:53:15 SID su[6770]: pam_unix(su:session): session closed for user nobody

Nun wenn ich also meine Ausgabe mit deiner vergleiche dann muss ich wohl davon ausgehen das es immer noch nicht funktioniert.

Aber noch sind ja die Versionen von systemd in Jessie und Sid die gleichen, daran kann es also nicht liegen.

[/quote]

Das ist das gleiche verhalten wie bei Pulsaudio, woher das wohl kommt? Nun da ich von der Dokumentation ausgeschlossen bin, kann ich nur mutmaßen oder raten woran es liegt bzw. liegen könnte. Ich hätte aber hier mehr Kompetenz erwartet bei soviel glühenden Systemd befürwortern.
Und ich habe noch ein paar sachen die mir mittlerweile sorgen machen, das sind probleme die ich vorher nicht hatte!
Wie zum beispiel das hier:

Code: Alles auswählen

Mai 06 20:16:36 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory)
Mai 06 20:16:36 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_now (No such file or directory)
Mai 06 20:16:36 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/power_now (No such file or directory)
Mai 06 20:16:52 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory)
Mai 06 20:16:52 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_now (No such file or directory)
Mai 06 20:16:52 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/power_now (No such file or directory)
Mai 06 20:17:24 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory)
Mai 06 20:17:24 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_now (No such file or directory)
Mai 06 20:17:24 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/power_now (No such file or directory)
Mai 06 20:17:25 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory)
Mai 06 20:17:25 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_now (No such file or directory)
Mai 06 20:17:25 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/power_now (No such file or directory)
Mai 06 20:17:30 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory)
Mai 06 20:17:30 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_now (No such file or directory)
Mai 06 20:17:30 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/power_now (No such file or directory)
Mai 06 20:17:44 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory)
Mai 06 20:17:44 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_now (No such file or directory)
Mai 06 20:17:44 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/power_now (No such file or directory)
Mai 06 20:17:57 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory)
Mai 06 20:17:57 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_now (No such file or directory)
Mai 06 20:17:57 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/power_now (No such file or directory)
Mai 06 20:18:01 tbbt kernel: CPU0: Core temperature above threshold, cpu clock throttled (total events = 1)
Mai 06 20:18:01 tbbt kernel: CPU0: Package temperature above threshold, cpu clock throttled (total events = 275)
Mai 06 20:18:01 tbbt kernel: CPU1: Package temperature above threshold, cpu clock throttled (total events = 275)
Mai 06 20:18:01 tbbt kernel: CPU0: Core temperature/speed normal
Mai 06 20:18:01 tbbt kernel: CPU0: Package temperature/speed normal
Mai 06 20:18:01 tbbt kernel: CPU1: Package temperature/speed normal
Mai 06 20:19:20 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory)
Mai 06 20:19:20 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_now (No such file or directory)
Mai 06 20:19:20 tbbt cpufreqd[1587]: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/power_now (No such file or directory)

oder

Code: Alles auswählen

Mai 06 19:00:12 tbbt kernel: ACPI Warning: SystemIO range 0x00000428-0x0000042f conflicts with OpRegion 0x00000400-0x0000047f (\PMIO) (20140424/utaddress-258)
Mai 06 19:00:12 tbbt kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Mai 06 19:00:12 tbbt kernel: ACPI Warning: SystemIO range 0x00000540-0x0000054f conflicts with OpRegion 0x00000500-0x00000563 (\GPIO) (20140424/utaddress-258)
Mai 06 19:00:12 tbbt kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Mai 06 19:00:12 tbbt kernel: ACPI Warning: SystemIO range 0x00000530-0x0000053f conflicts with OpRegion 0x00000500-0x00000563 (\GPIO) (20140424/utaddress-258)
Mai 06 19:00:12 tbbt kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Mai 06 19:00:12 tbbt kernel: ACPI Warning: SystemIO range 0x00000500-0x0000052f conflicts with OpRegion 0x00000500-0x00000563 (\GPIO) (20140424/utaddress-258)
Mai 06 19:00:12 tbbt kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Mai 06 19:00:12 tbbt kernel: lpc_ich: Resource conflict(s) found affecting gpio_ich

Ich vermute mal das dies auch hiermit zusammenhängt:
https://www.debian.org/releases/jessie/ ... idp1029168
Ohne Doku keine migration zu logind, ich vermute mal das die Entwickler genau wissen das es hier schwere inkompatibilitäten und fehlfunktionen gibt. Für diese Leute mag ja gelten das Hardware nix kostet, für mich gilt das nicht, und zur zeit befürchte ich das Debian meinen Rechner zerstört, wegen magelhafter Software! *grml*

[niesommer]

Einen richtigen cron- bzw. anacron-Dienst gibt es bei dir nach der Installation von systemd-cron nicht mehr, deshalb gibt dir systemctl auch keinen Status dazu aus. Das Paket baut die Funktionsweise von (ana)cron mit ein paar systemd-Timer-Beschreibungen nach:

Code: Alles auswählen

$ dpkg -L systemd-cron | grep timer
/lib/systemd/system/cron-monthly.timer
/lib/systemd/system/cron-daily.timer
/lib/systemd/system/cron-weekly.timer
/lib/systemd/system/cron-hourly.timer

Ja das sieht bei mir auch so aus.

Timer sind ein Feature von systemd – eins der vielen, die bestehende Lösungen ersetzen wollen – mit dem man Dienste und anderes wie mit cron zu bestimmten Zeitpunkten ausführen kann. Prinzipiell ist es so gedacht, dass man dies „nativ“ für systemd mit .timer-Dateien konfiguriert (man systemd.timer), mit dem Paket oben kann man aber auch die cron-Konfiguration (vorerst (?)) weiter verwenden.

weiter verwenden wäre schön wie zu sehen ist funktioniert es nicht so wie es soll, aber vorsicht ich muss leider nur raten wissen wäre natürlich besser.

Du kannst dir anscheinend Logs der einzelnen Timer angucken (aus man systemd.cron):

Code: Alles auswählen

# journalctl -u cron-boot
# journalctl -u cron-hourly
# journalctl -u cron-daily
# journalctl -u cron-weekly
# journalctl -u cron-monthly
# journalctl -u cron-yearly

Da steht allerdings (bei mir zumindest) nicht viel drin.

Das sieht bei mir so aus:

Code: Alles auswählen

journalctl -u cron-daily
-- Logs begin at Di 2015-05-05 12:32:53 CEST, end at Mi 2015-05-06 20:48:12 CEST. --

Und auch den Zeitpunkt, wann sie das nächste Mal ausgeführt werden:

Code: Alles auswählen

$ systemctl list-timers

.

Ja hier bekomme ich folgende ausgabe:

Code: Alles auswählen

 systemctl list-timers
NEXT                         LEFT                LAST                         PASSED       UNIT                         ACTIVATES
Mi 2015-05-06 21:00:00 CEST  9min left           Mi 2015-05-06 20:00:25 CEST  50min ago    cron-hourly.timer            cron-hourly.target
Do 2015-05-07 00:00:00 CEST  3h 9min left        Mi 2015-05-06 18:28:13 CEST  2h 22min ago cron-daily.timer             cron-daily.target
Do 2015-05-07 07:30:00 CEST  10h left            Mi 2015-05-06 18:28:13 CEST  2h 22min ago cron-root-0.timer            cron-root-0.service
Do 2015-05-07 19:15:05 CEST  22h left            Mi 2015-05-06 19:15:05 CEST  1h 35min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mo 2015-05-11 00:00:00 CEST  4 days left         Mi 2015-05-06 18:28:13 CEST  2h 22min ago cron-weekly.timer            cron-weekly.target
Mo 2015-06-01 00:00:00 CEST  3 weeks 4 days left Mi 2015-05-06 18:28:13 CEST  2h 22min ago cron-monthly.timer           cron-monthly.target

6 timers listed.
Pass --all to see loaded but inactive timers, too.

anacron.service scheint bei dir noch mit einem Link /etc/systemd/system/anacron.service -> /dev/null maskiert zu sein. Den könntest du entfernen, er stört aber auch nicht.

Das steht da zumindest, aber was bedeutet es und warum macht man sowas?

[niesommer]

So heute scheint es mein Rechner gar nicht gut mit mir zu meinen, nach dem ich meinen Rechner zu klappte und ihn einige Zeit später wieder aufklappte war die Netzwerkverbindung weg, ich habe jetzt gerade eine kleine Ewigkeit gebraucht herauszufinden wie man die netzwerk Verbindung wieder aktivieren kann. Auch etwas was ich schon lange nicht mehr erlebt habe, vielleicht sollte ich für heute den Rechner ausmachen. Wenn das so weiter geht hänge ich debian an den Nagel!

[NAB]

Von diesen hin und herschalten halte ich noch nicht allzuviel, von daher ist das im moment keine Option für mich.
Die Auseinandersetzung mit systemd wird zu einem Problem für mich denn es gibt keine deutschsprachige dokumentation, die manualpages (man) sind soweit ich gesehen habe d.h. die die ich mir angesehen habe sind alle in englisch und für mich nicht verständlich.

Ich meinte damit auch nicht, dass du dauernd hin- und herspringen sollst, sondern dass du sysvinit so auf ungefährliche Weise ausprobieren kannst. Wobei ich gerade gesehen habe, dass auch eine Jessie-Neuinstallation im Advanced-Bereich von Grub die Möglichkeit bietet, per sysvinit zu starten.

Probiere es doch einfach mal aus und schau, ob du damit besser klar kommst, bevor du Debian den Rücken kehrst.

Ich halte die bisherige Integration von Systemd in Jessie für recht ungeschliffen und schlecht dokumentiert. Und Systemd in Jessie ist bereits jetzt hoffnungsslos veraltet, es macht also nur begrenzt Sinn, sich jetzt schon damit auseinandersetzen zu wollen. In zwei Jahren wird das bestimmt besser aussehen.

Code: Alles auswählen

Mai 06 19:00:12 tbbt kernel: ACPI Warning: SystemIO range 0x00000428-0x0000042f conflicts with OpRegion 0x00000400-0x0000047f (\PMIO) (20140424/utaddress-258)
Mai 06 19:00:12 tbbt kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

Diese Meldung hat absolut nichts mit Systemd zu tun, sondern kommt vom Kernel. Der versucht zunehmend, die Hardware von ACPI verwalten zu lassen, statt für jede Kleinigkeit einen eigenen Treiber mit direktem Hardware-Zugriff laufen zu lassen. Das betrifft üblicher Weise Sensoren auf dem Mainboard für Temperatur, Spannungen und Lüftergeschwindigkeit. Solche Fehler habe ich auch, auf "etwas älteren" Mainbords. Da macht sich anscheinend niemand mehr die Mühe, dafür ACPI-Treiber zu schreiben. Als einzigen negativen Effekt habe ich bisher festgestellt, dass die Ausgaben von lm-sensors dann etwas spärlicher ausfallen.

Code: Alles auswählen

/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory)

Das hier dürfte was mit deiner BATterie zu tun haben, also deinem Akku. Treten diese Meldungen vielleicht nur auf, wenn das Gerät am Netzstorm hängt? Oder gar, wenn der Akku entfernt ist?

Aber ... eine Gefahr für deine Hardware kann ich bisher nicht erkennen

[niesommer]

Ich halte die bisherige Integration von Systemd in Jessie für recht ungeschliffen und schlecht dokumentiert.

Da stimme ich Dir zu! Und muss dazu sagen das es den Unfertigsten Eindruck macht den ich bei einem Debian je erlebt habe.

Und Systemd in Jessie ist bereits jetzt hoffnungsslos veraltet, es macht also nur begrenzt Sinn, sich jetzt schon damit auseinandersetzen zu wollen. In zwei Jahren wird das bestimmt besser aussehen.

Dann hätte die Debian Entwickler das einfach noch nicht zu Standard machen sollen und sich lieber zeit für eine ordentliche Umsetzung und Integration in Debian 9 anstreben sollen. Hier zeigt sich sehr deutlich was für eine Fehlentscheidung dies war.

Code: Alles auswählen

/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory)

Das hier dürfte was mit deiner BATterie zu tun haben, also deinem Akku. Treten diese Meldungen vielleicht nur auf, wenn das Gerät am Netzstorm hängt? Oder gar, wenn der Akku entfernt ist?

Das werde ich überprüfen, danke für den Tip!

Aber ... eine Gefahr für deine Hardware kann ich bisher nicht erkennen

Das ist beruhigend, danke.

[guennid]

jessie geht noch ohne gnome und systemd.

Grüße, Günther

[niesommer]

jessie geht noch ohne gnome und systemd.

Grüße, Günther

Das mag schon sein, ist aber nicht Zielführend; führt aber dazu Debian aufzugeben.
Debian Jessie auf meinem Mac Mini Powerpc ist ohne systemd dafür aber auch nicht brauchbar und benutzbar, an der stelle scheint der grafiktreiber nicht mehr zu funktionieren, mittlerweile habe ich aufgegeben und wieder Debian Wheezy installiert, der Mac mini läuft jetzt erstmal wieder fehlerfrei. Mir scheint Debian Jessie ein sehr schlechtes Release zu sein, auch ohne systemd.

[guennid]

führt aber dazu Debian aufzugeben.

Kann ich noch nicht sehen. Devuan wird meiner Meinung nach nichts. Jessie ist noch neu, mal sehen, wie sich das weiterentwickelt. Aber ich mach's im Grunde wie du: der Hauptrechner bleibt auf wheezy, bei den anderen probiere ich jessie ohne systemd und einer kriegt halt das Teil, man muss ja lernen.

Grüße, Günther

[niesommer]

Devuan wird meiner Meinung nach nichts.

Bis jetzt ist davon noch nichts zu sehen, ich bin da auch sehr skeptisch und sehe das nicht als alternative.

Jessie ist noch neu, mal sehen, wie sich das weiterentwickelt.

Haha..., weiterentwickelt ist gut. kaputt entwickeln trifft es mal wieder.

einer kriegt halt das Teil, man muss ja lernen.
Grüße, Günther

So das ist jetzt etwas OT:
Ja, genau das tue ich gerade, und es tun sich abgründe auf. nicht nur in der umsetzung und integration sondern leider auch in der Dokumentation. Kein wunder das MS die veröffentlichung von Jessie feiert.
http://www.pro-linux.de/news/1/22263/mi ... ian-8.html
https://www.google.de/#q=microsoft+feiert+debian