PyAutoMnt

Stellt hier eure Projekte vor.
Internetseiten, Skripte, und alles andere bzgl. Python.
Antworten
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Mich hats genervt immer von Hand zu mounten und zu umounten, dann hab ich mir diesen kleinen Helfer geschrieben: Sobald ein USB-Stick, USB-Volume per usb eingesteckt wird, wird der gemounted, falls ein Eintrag in der fstab existiert, wird der berücksichtigt.
Das Ganze funktioniert mit dbus über den HAL und subprocess, zusätzlich ist es möglich, aus dem Skript einen daemon zu machen.

PyAutoMnt

Ein Startskript für /etc/rc.d (Archlinux) könnte so aussehen

Code: Alles auswählen

#!/bin/bash

# config
. /etc/rc.conf
. /etc/rc.d/functions

PROGFILE="/usr/bin/pyautomnt"
PIDFILE="/var/run/pyautomnt.pid"

case "$1" in
  start)
    # check if hal is running, if not start hal
    ck_daemon hal && /etc/rc.d/hal start
    stat_busy "Starting pyautomnt"
    $PROGFILE -d &>/dev/null
    if [ $? -gt 0 ]; then
      stat_fail
    else
      add_daemon pyautomnt
      stat_done
    fi
    ;;
  stop)
    stat_busy "Stopping pyautomnt"
    if [ -f "$PIDFILE" ]; then
      kill `cat $PIDFILE` &> /dev/null
      if [ $? -gt 0 ] && ps --no-heading -p `cat $PIDFILE` &> /dev/null; then
        stat_fail
      else
        rm -f $PIDFILE &> /dev/null
        rm_daemon pyautomnt
        stat_done
      fi
    else
      stat_fail
    fi
    ;;
  restart)
    $0 stop
    sleep .5
    $0 start
    ;;
  *)
    echo "usage: $0 {start|stop|restart}"
esac
exit 0
//Edit:
der Highlighter mach aus & ein & - wenn ich editieren will, zeigt er wieder ein & an
the more they change the more they stay the same
lunar

Kann das Deine Desktop-Umgebung nicht selbst?!

Wenn Du mount selbst aufrufst, solltest Du die von HAL gesetzten mount-Optionen berücksichtigen. Sinnvoller ist es allerdings, direkt HAL zum Einbinden zu nutzen. Dann musst Du mount nicht selbst aufrufen, und auch /etc/fstab nicht selbst parsen. libudev und/oder devicekit-disks wäre im Übrigen wahrscheinlich die modernere Kombination.

Ach ja, statt das Forking selbst zu implementieren, würde ich einfach "start-stop-daemon" nutzen, um das Skript auszuführen. In jedem Fall ist der zweite fork() bei diesem Quelltext nicht nötig.

Im Übrigen kannst Du auch gleich HAL zum Mounten nutzen, wenn Du es eh nutzt, um auf Geräte zu reagieren. Dann musst Du mount nicht manuell aufrufen, und auch "/etc/fstab" nicht selbst parsen.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Nein, dwm (DynamicWindowManager) kann das nicht, ich hab nur nen weg über udev gefunden (was aber nix mit dem WM zu tun hat). Über HAL mounten, das hab' ich versucht, allerdings hat es nicht geklappt.

Ich hatte nicht wirklich eine Ahnung, wie ich aus diesem Skript einen Daemon mache => ich hab das (wie man am comment erkennt) kopiert. Allerdings glaub ich einigermaßen verstanden zu haben wie es geht, der 2. fork ist doch nötig, dass ich nicht session leader werden kann, wieso ist der 2. fork denn nicht nötig?

start-stop-daemon?

Nochmal zum Mounten mit dem HAL, ich denke, das werde ich mir nochmal genauer anschauen (Veränderungen im Repo)

//Edit: was ich noch ändern will: versuchen statt atexit das signals Modul zu nutzen, so in etwa: signal.signal(signal.SIGTERM, handler)
the more they change the more they stay the same
lunar

dwm ist doch nur eine Fensterverwaltung, das hindert Dich doch nicht daran, die Funktionalität einer beliebigen Desktop-Umgebung zum Einhängen zu nutzen. Naja, ist ja Deine Sache.

Der zweite fork() führt dazu, dass der Prozess nicht mehr session leader ist, ja. Das dient nur dazu, zu vermeiden, dass der Prozess je ein neues controlling terminal erhält. Das geschieht allerdings nur, wenn der Prozess irgendwann eine TTY-Gerätedatei öffnet. In Deinem Quelltext ist das nie der Fall. Und da in Deinem Quelltext auch ohne zweiten fork() keine Zombies entstehen können, ist der zweite fork() überflüssig.

start-stop-daemon ist ein Programm, welches die Dämon-Magie und nebenbei noch andere Dinge wie PID-Dateien usw. für Dich übernimmt. Damit kannst Du ein normales Programm zum Dämon machen und musst Dich um das Forken usw. nicht kümmern.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Danke für die Erklärung und den Link, wenn ich was größeres im Code ändere schreib ichs hier (vllt. interessierts jemanden), den Rest kann man ja auf bitbucket verfolgen.
the more they change the more they stay the same
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Wie wäre es mit skvm? Das nutzt hal/fstab und es gibt einen Fork, der pmount benutzt (den ich zufällig in meine github-Repo habe :P)

skvm ist ~ 1000 Zeilen C und nutzt iirc hal und dbus.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Mh, skvm kann doch auch nicht mehr als mounten, umounten oder?

PS: hab jetzt signals hinzugefügt und das 2. forken entfernt
the more they change the more they stay the same
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Nochmal zum Mounten mit HAL, ich müsste die fstab doch trotzdem parsen, da org.freedesktop.Hal.Device.Volume.Mount als Parameter diese haben will:

Code: Alles auswählen

String mount_point, String fstype, String[] options
//Edit: Quelle: http://www.marcuscom.com/hal-spec/hal-s ... ice-volume
the more they change the more they stay the same
lunar

@Dav1d: Warum musst Du jetzt deswegen die fstab parsen? Alle für diesen Aufruf benötigten Parameter liefert HAL Dir schon.
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Dav1d hat geschrieben:Mh, skvm kann doch auch nicht mehr als mounten, umounten oder?
Nein, aber es ist C. :)
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Ich hab jetzt probiert mit HAL zu mounten, ging eher nicht :P

Wenn ein fstab Eintrag existiert:

Code: Alles auswählen

Python 2.6.5 (r265:79063, Apr  1 2010, 05:22:20) 
[GCC 4.4.3 20100316 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import dbus
>>> sb = dbus.SystemBus()
>>> po = sb.get_object('org.freedesktop.Hal', '/org/freedesktop/Hal/devices/volume_uuid_08706D4F706D4492')
>>> ifa = dbus.Interface(po, 'org.freedesktop.Hal.Device.Volume')
>>> ifa.Mount('/media/test', 'ntfs-3g', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.Hal.Device.Volume.PermissionDenied: Device /dev/sdb1 is listed in /etc/fstab. Refusing to mount.
Und wenn kein fstab Eintrag existiert

Code: Alles auswählen

>>> ifa.Mount('/media/test', 'ntfs-3g', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.Hal.Device.Volume.UnknownFailure: mount_point cannot contain the following characters: newline, G_DIR_SEPARATOR (usually /)
Irgendwie verwirrend.

Und was ist an C besser?
the more they change the more they stay the same
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

mount_point cannot contain the following characters: newline, G_DIR_SEPARATOR (usually /)
ist doch selbsterklärend, oder? Ich denke, du solltest nicht "/media/blah" angeben, sondern nur "blah".

C-Programme kann man statisch linken und dann braucht man zum Beispiel keinen dicken Python-Interpreter mit 10 Modulen laden, was ja alles Zeit und Nerv kostet ;)
lunar

Ins Blaue geraten, würde ich einfach mal annehmen, dass HAL sinnvollerweise nicht erlaubt, Datenträger mit Nutzerrechten an beliebige Ort zu mounten. Man darf also keinen absoluten Pfad angeben, sondern nur einen Verzeichnisnamen, an dem der Datenträger dann unterhalb von "/media" eingehängt wird. Ich finde das eigentlich nicht verwirrend, sondern ziemlich logisch ...

Ebenso erlaubt HAL nicht, in der fstab eingetragene Datenträger einzubinden, weil man sonst ja dort eingetragene Mount-Optionen umgehen könnte. Deswegen trägt man Wechseldatenträger ja auch nicht in der fstab ein.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

:oops: schon spät :P

Danke, auf die Idee kam ich nicht...
Was richtig schön ist, dass der HAL den USB-Stick o.a. von alleine umounted (also wenn er rausgezogen wird). Ich beschäftige mich mal morgen damit weiter
the more they change the more they stay the same
Antworten