systemd und diverse Probleme

04/07/2014 - 22:39 von Andreas Kohlbach | Report spam
Heute hat Debian (Jessie) endgültig den sysvinit-core rausgeworfen, dass
alles auf systemd làuft. Ich könnte aber nicht sagen, dass er nun
schneller bootet, mir gar einbilden, er ist etwas langsamer geworden.

Zu den Problemen aber:

Er ignorierte (hat nicht importiert) die Einstellungen, wann es in /tmp
aufràumen soll. So das er alles hier abgeràumt hat. Kein Problem, da man
ja keine wichtigen Dinge dort aufbewahren soll. Trotzdem hàtte er IMO die
Einstellungen TMPTIME=8 aus /etc/default/rcS übernehmen müssen.

Ich habe man tmpfiles.d gelesen, und es so verstanden, dass
/usr/lib/tmpfiles.d/tmp.conf nun dafür zustàndig ist. Dort gab es
u.a. die Zeilen

| D /tmp 1777 root root -
| #d /var/tmp 1777 root root 30d

Ich habe die obere Zeile durch

| D /tmp 1777 root root 8d

ersetzt und neu gebootet. Ich habe das dann wohl falsch verstanden, da er
immer noch alles in /tmp abràumt, inklusive die Test Dateien, die ich dort
vorher platzierte. Auch es nicht ganz richtig ist, weil "-" wohl für
"access mode" steht, und nicht für "zero", wie ich erst dachte, sollte
das Weglassen dann den "default access mode" setzen.

Wie ist es richtig, so dass er nur Dateien dort löscht, die àlter als 8
Tage sind?

Weiter startete alle Services von sich aus. Auch die, die ein K in den
alten Runlevel-Verzeichnissen hatte. Auch da hàtte er die Einstellungen
übernehmen müssen. Gut, dass ich mal mit nmap mich selbst scannte...

Ein paar konnte ich via "systemctl disable fubar" deaktivieren, so dass
sie beim nàchsten Boot nicht wieder kamen. Wie für ssh oder vsftpd. Andere
aber, wie "samba" (auch mir "smbd" und "nmbd" versucht) kommen trotzdem
wieder hoch. So auch cups (ipp). Dazu die Meldungen:

| insserv: warning: current start runlevel(s) (empty) of script `cups'
| overrides LSB defaults (2 3 4 5).
| insserv: warning: current stop runlevel(s) (1 2 3 4 5) of script `cups'
| overrides LSB defaults (1).

beim Versuch ihn nochmal mit "systemctl disable cups" dazu zu bewegen,
beim nàchsten Boot nicht mehr zu starten.

Heißt dass, dass das "cups script" (was auch immer damit gemeint ist, und
wo immer es auch liegen mag) mit systemd nicht kompatibel ist? Google hat
Treffer dazu auch im Zusammenhang mit sysvinit und upstart, dass das eher
noch verworrener für mich wird.

Schlussendlich habe ich Privoxy, der sich nun, und ohne Fehlermeldung,
nicht mehr zum Starten überreden lassen will. Weder beim Boot, noch von
Hand gestartet. Auch der "old school" Versuch

service privoxy start

macht nichts. Weder Meldung, noch Erfolg (Portscan zeigt den
dazugehörigen Port geschlossen). Früher ging das so.

Hülfe! :-)
Andreas

I wish my grass was emo. Then it would cut itself.
 

Lesen sie die antworten

#1 Sven Hartge
04/07/2014 - 22:41 | Warnen spam
Andreas Kohlbach wrote:

Heute hat Debian (Jessie) endgültig den sysvinit-core rausgeworfen, dass
alles auf systemd làuft. Ich könnte aber nicht sagen, dass er nun
schneller bootet, mir gar einbilden, er ist etwas langsamer geworden.



Grundsàtzlich ist systemd noch nicht der Default. Irgendeine
Abhàngigkeit wird es bei dir ins System gezogen haben.

Ich habe die obere Zeile durch

| D /tmp 1777 root root 8d

ersetzt und neu gebootet. Ich habe das dann wohl falsch verstanden, da er
immer noch alles in /tmp abràumt, inklusive die Test Dateien, die ich dort
vorher platzierte. Auch es nicht ganz richtig ist, weil "-" wohl für
"access mode" steht, und nicht für "zero", wie ich erst dachte, sollte
das Weglassen dann den "default access mode" setzen.



Ist /tmp bei die aktuell zufàllig ein tmpfs? Dann wàre es nicht
wunderlich, dass einem Boot alles weg ist.



Sigmentation fault. Core dumped.

Ähnliche fragen