Das deutsche Python-Forum

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

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.

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)

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.

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.

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.

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

PS: hab jetzt signals hinzugefügt und das 2. forken entfernt

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

@Dav1d: Warum musst Du jetzt deswegen die fstab parsen? Alle für diesen Aufruf benötigten Parameter liefert HAL Dir schon.

Dav1d hat geschrieben:Mh, skvm kann doch auch nicht mehr als mounten, umounten oder?

Nein, aber es ist C. :)

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

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?

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 ;)

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.

schon spät

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

Das deutsche Python-Forum

PyAutoMnt

PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt

Re: PyAutoMnt