Debian auf CF-Karte vs. Jessie ( d.h. systemd :-| )

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
plankton

Debian auf CF-Karte vs. Jessie ( d.h. systemd :-| )

Beitrag von plankton » 25.10.2014 21:57:54

N'abend allerseits,

wie bilde ich denn folgendes Szenario korrekt unter systemd nach?

Code: Alles auswählen

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system>  <mount point>  <type>  <options>  <dump>  <pass>
UUID=...  /           ext2   noatime,errors=remount-ro  0  1
tmpfs     /tmp        tmpfs  noatime                    0  0
tmpfs     /var/lock   tmpfs  noatime                    0  0
tmpfs     /var/log    tmpfs  noatime                    0  0
tmpfs     /var/run    tmpfs  noatime                    0  0
tmpfs     /var/spool  tmpfs  noatime                    0  0
tmpfs     /var/tmp    tmpfs  noatime                    0  0
tmpfs     /var/www    tmpfs  noatime                    0  0

Code: Alles auswählen

#! /bin/sh

### BEGIN INIT INFO
# Provides:          flashupdown
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# X-Start-Before:    cron lighttpd $syslog
# X-Stop-After:      cron lighttpd $syslog
### END INIT INFO

. /lib/lsb/init-functions

case "$1" in
  start)
    log_begin_msg "Uncompressing log/spool/www files from flash card to tmpfs..."
    tar xfz /var/var_compressed/log.tar.gz -C /
    tar xfz /var/var_compressed/spool.tar.gz -C /
    tar xfz /var/var_compressed/www.tar.gz -C /
    log_end_msg 0
    ;;
  stop)
    log_begin_msg "Compressing log/spool/www files from tmpfs to flash card..."
    tar cfz /var/var_compressed/log.tar.gz --directory=/ var/log/
    tar cfz /var/var_compressed/spool.tar.gz --directory=/ var/spool/
    tar cfz /var/var_compressed/www.tar.gz --directory=/ var/www/
    log_end_msg 0
    ;;
  *)
    echo "Usage: $0 {start|stop}"
    exit 1
    ;;
esac

exit 0
Ich habe sowohl versucht, ihm das alte Init-Skript unterzujubeln (was seit Ewigkeiten funktioniert hat), als auch das über einen systemd-Service nachzubilden.

Leider fliegt mir der Kram auch nach einem halben vertrödelten Wochenende stetig um die Ohren: Mount-Targets Failure hier, Dependency Error da, Emergency Console, journalctl sagt gar nichts, D-BUS Error, selbst Reboot geht nicht weil Daemon nicht läuft, bla blubb.

(Auf wievielen Sachen hat dieser systemd-Kram seine Finger eigentlich mittlerweile drauf? Darf man heutzutage überhaupt noch selbst irgendwas anpacken und entsprechend der eigenen Bedürfnisse modifizieren, ohne dass irgendwelche undurchsichtigen Automatismen den Geist aufgeben? :evil:)

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: Debian auf CF-Karte vs. Jessie ( d.h. systemd :-| )

Beitrag von catdog2 » 26.10.2014 01:53:00

Spontan könnte er sich schon mal an den tmpfs mounts für /var/run und /var/lock stören, das sind ja heutzutage symlinks nach /run bzw. /run/lock womit du /run übermountest wo systemd auf jeden Fall Dinge ablegt.

Ansonsten wäre wohl eine genauere Fehlerbeschreibung hilfreich.
Unix is user-friendly; it's just picky about who its friends are.

Benutzeravatar
smutbert
Beiträge: 8350
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Debian auf CF-Karte vs. Jessie ( d.h. systemd :-| )

Beitrag von smutbert » 26.10.2014 10:01:01

/run (/var/run ist genau wie /var/lock nur ein Link darauf) landet mit systemd doch sowieso auf einem tmpfs, hier auf meinem jessie

Code: Alles auswählen

$ mount | grep tmpfs
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1920443,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=3076336k,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
tmpfs on /tmp type tmpfs (rw)
tmpfs on /run/user/107 type tmpfs (rw,nosuid,nodev,relatime,size=1538168k,mode=700,uid=107,gid=116)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1538168k,mode=700,uid=1000,gid=100
/tmp ist eine eigene Geschichte:
Ursprünglich hat systemd (meiner Meinung nach sinnloserweise) /tmp ebenfalls standardmäßig auf ein tmpfs gelegt, aber Debian hat das abgeschaltet. Aktivieren läßt sich dieses Verhalten wieder mit

Code: Alles auswählen

# systemctl enable tmp.mount
nach einem Neustart sieht es so aus, wie oben gepostet und

Code: Alles auswählen

$ systemctl status tmp.mount
● tmp.mount - Temporary Directory
   Loaded: loaded (/lib/systemd/system/tmp.mount; enabled)
   Active: active (mounted) since Son 2014-10-26 08:39:21 CET; 1h 16min ago
    Where: /tmp
     What: tmpfs
     Docs: man:hier(7)
           http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
  Process: 192 ExecMount=/bin/mount -n tmpfs /tmp -t tmpfs -o mode=1777,strictatime (code=exited, status=0/SUCCESS)
Dann denke ich fehlt dir nur mehr spool, www und log. Für letzteres könntest du dir ramlog [1] ansehen, das funktioniert auf meinem Cubietruck (allerdings unter Wheezy) unauffällig.

[1] http://www.tremende.com/ramlog/#install_2

plankton

Re: Debian auf CF-Karte vs. Jessie ( d.h. systemd :-| )

Beitrag von plankton » 27.10.2014 22:10:21

Ohne /var/run und /var/lock bootet er nun zumindest schon mal wieder ohne Ermergency. "systemctl enable tmp.mount" hat für /tmp auch funktioniert.

Habe es nun nochmal nur mit /var/log, /var/spool und /var/www versucht.

Der im Skript formulierte Wunschzeitpunkt, wann das Sichern bzw. Zurückspielen passieren soll, scheint aber leichte Verwirrung in Form von Zirkelbezügen zu verursachen, wenn ich das richtig deute. :?

Code: Alles auswählen

systemd[1]: Job systemd-journald.service/start deleted to break ordering cycle starting with basic.target/start
systemd[1]: Job sockets.target/start deleted to break ordering cycle starting with basic.target/start
systemd[1]: Job systemd-journald-dev-log.socket/start deleted to break ordering cycle starting with systemd-journald.service/st
systemd[1]: Unable to break cycle

plankton

Re: Debian auf CF-Karte vs. Jessie ( d.h. systemd :-| )

Beitrag von plankton » 28.10.2014 18:41:33

OK, nächster Versuch. Folgendes scheint nun zu funktionieren:

Code: Alles auswählen

[Unit]
Description=CF card sync
After=local-fs.target
Before=cron.service lighttpd.service syslog.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/root/bin/flashupdown start
ExecStop=/root/bin/flashdown stop

[Install]
WantedBy=multi-user.target
Nachdem ich es geschafft habe, dass er beim Booten überhaupt mal irgendwelche Meldungen ausgibt, konnte ich verifizieren, dass er beim Hochfahren die richtige Reihenfolge einhält.

Die einzige Frage, die ich jetzt noch habe (außer "Ist das richtig so?") ist: bedeutet dieser Satz aus der Doku
Note that when two units with an ordering dependency between them are shut down, the inverse of the start-up order is applied.
, dass es kein Äquivalent zu "X-Stop-After" gibt und er das automatisch richtig macht?

Benutzeravatar
smutbert
Beiträge: 8350
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Debian auf CF-Karte vs. Jessie ( d.h. systemd :-| )

Beitrag von smutbert » 28.10.2014 19:34:41

ja, so würde ich es deuten

plankton

Re: Debian auf CF-Karte vs. Jessie ( d.h. systemd :-| )

Beitrag von plankton » 28.10.2014 20:50:17

Hm, dann lass ich das jetzt erstmal so. Funktioniert ja offensichtlich so weit.

Für die Zeit, die ich jetzt gebraucht habe, hätte ich mir zwar eine 5kg-Packung CF-Karten kaufen und die bis ans Lebensende kaputt schreiben können... :facepalm:

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: Debian auf CF-Karte vs. Jessie ( d.h. systemd :-| )

Beitrag von catdog2 » 28.10.2014 21:05:05

Evtl, könntest du

Code: Alles auswählen

DefaultDependencies=no
Before=Basic.target
ausprobieren, anstatt irgendwelche einzelne services aufzuzählen (man systemd.special)
Nachdem ich es geschafft habe, dass er beim Booten überhaupt mal irgendwelche Meldungen ausgibt, konnte ich verifizieren, dass er beim Hochfahren die richtige Reihenfolge einhält.
Könnte man mit systemd-analyze verifizieren, z.B.

Code: Alles auswählen

systemd-analyze plot > irgendwas.svg
Unix is user-friendly; it's just picky about who its friends are.

Antworten