File: LIESMICH.spool

package info (click to toggle)
sendfile 2.1b.20080616-10
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 2,148 kB
  • sloc: ansic: 13,128; sh: 4,193; perl: 844; makefile: 132; java: 36; csh: 3
file content (72 lines) | stat: -rw-r--r-- 2,926 bytes parent folder | download | duplicates (11)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
Mit sendfile 1.6-19970708 ist echtes asynchrones Verschicken ueber
einen Outgoing Spool verfuegbar. Eigentlich war der Code schon seit fast 1
Jahr drin und wartete nur darauf, dass ich ihn endlich mal debuggte und
fertig stellte. Nun isses so weit :-)

sendfile hat dafuer 2 neue Optionen zur Verfuegung:
	
	-S  sendet nicht direkt, sondern legt das File im Outgoing Spool ab 
	-l  listet Files im Outgoing Spool 
	

Beispiel:

moep:~/sendfile/sendfile-1.6> sendfile -S Makefile framstag@bofh.belwue.de
%sendfile-I, 'Makefile' spooled

moep:~/sendfile/sendfile-1.6> sendfile -l
Files in outgoing spool:

framstag@bofh.belwue.de : Makefile


Oder etwas ausfuehrlicher:

moep:~/sendfile/sendfile-1.6> sendfile -Suv makeconfig framstag@bofh.belwue.de
%sendfile-I, makeconfig is of type: Bourne shell script text
%sendfile-I, 'makeconfig' spooled
220 moep.bb.bawue.de SAFT server (sendfiled 1.6 on Linux) ready.
-> START SPOOLDAEMON
200 Command ok.


Wie man sieht, nimmt sendfile am Ende noch schnell Kontakt zum eigenen
sendfiled auf und sagt ihm, er solle den spooldaemon starten. 

Der sendfile spool daemon ist im normalen sendfiled enthalten und wird von
diesem via fork gestartet. Fuer jeden Zielhost, den er im Outgoing Spool
findet, wird erneut ein sfsd geforkt, der dann versucht zu diesem host
eine Verbindung aufzubauen. Dies habe ich gemacht, um zu verhindern, dass
sich die tcp-timeouts zu sehr addieren. Alternativ kann ueber die
sendfile.cf Option parallel=off auch erzwungen werden, dass nur ein sfsd
laeuft, der alles hintereinander abarbeitet. Ist ein Host nicht
erreichbar, so wird fuer X Minuten gewartet, um es erneut zu versuchen.
Kommt es nach Y Tagen zu keiner erfplgreichen Uebertragung, so wird das
betreffende File an den Absender zurueckgeschickt; genauer gesagt: es
landet in dessen Incomming Spool. X und Y sind in sendfile.cf
konfigurierbar ueber die Optionen retry und bounce.

Der Absender kann aber auch Files aus dem Outgoing Spool loeschen, Beispiel:

moep:~> sendfile -Sd Makefile framstag@bofh.belwue.de
%sendfile-I, deleted from outgoing spool: 'Makefile' for framstag@bofh.belwue.de


Die Abarbeitung der Outgoing Queue kann aber auch von root direkt
angestossen werden mit: sendfiled -q

Dabei wird nur einmal versucht auszuliefern und nicht in einer
Endlosschleife.

Es ist trotzdem zu empfehlen in das System Bootscript folgende Zeile
aufzunehmen:
	/usr/local/sbin/sendfiled -Q
Damit wird sichergestellt, dass liegengebliebene Files im outgoing spool
gleich weiterverarbeitet werden und nicht erst wenn der naechste User es
mit sendfile anstoesst.

Anmerkung: der sendfile spool daemon arbeitet mit locking und kommt daher
nicht durcheinander wenn versucht wird ihn mehrfach zu starten. Spaeter
gestartete sendfile spool daemon terminieren einfach, wenn sie merken,
dass die queue bereits abgearbeitet wird. Nur "sendfiled -q" arbeitet die
outgoing spool queue in jedem Fall einmal ab.