--===============0541786592==
Content-Type: multipart/alternative;
boundary="=====================_352907546==.ALT"

--=====================_352907546==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:55 AM 9/14/2006, Oliver Cruickshank wrote:

>Hi,
>We're using proftpd 1.3.0 on AIX 5.2. We receive lots of files from
>trading partners and to avoid polling hundreds of directories we monitor
>the xferlog to see what has been received.
>
>To make sure we don't miss anything, the xferlog file has been converted to
>a FIFO/named pipe( as per
>http://www.castaglia.org/proftpd/doc...O-Logging.html)
>
>Reading the xferlog FIFO is a small Java program. If nothing is reading
>the FIFO (e.g. if the Java program crashes) we want to make sure that no
>files are processed (we don't want to miss anything).


So is your FIFO-reader crashing? Or are you working out your
failure-recovery options?

>If the FIFO reader is not running when a new user logs in, it works fine -
>FTP hangs after the log in screen. However for users already logged in, if
>the FIFO reader crashes then they can still transfer data and no xferlog
>information is captured anywhere.


Well, this _is_ a flaw - not captured anywhere?

To point out why this seems snide (and probably is), I don't use
FIFO's currently. I do everything using an xferlog _logfile_
reader. It passively trails the log, detecting when new entries are
added and acting on that information.

And I _have_ had the reader crash and/or fail to start. And the
upshot of that was that when I noticed it wasn't running I started it
again, and it resumed from where it left off, processing all the
transfers _since_ the point when it died. Sometimes that's been a
whole lot of processing all at once, but no one outside the server noticed.

I guess my bias has always been towards the passive, "outside the
process", type of monitoring. I don't want processing
(uploads/logins) to stop if something non-FTP-ish has
died. Something like "what is the least invasive, least coupled way
to do this?"

(Hope this doesn't come across too snide - please consider it an
alternative viewpoint)

>is there a way round this? (to stop all transfers if the xferlog FIFO
>reader has crashed)
>
>
>Alternatively we could have a program monitor the FIFO reader and do an
>"ftpshut now" to log off all users and prevent new users logging in.
>However this does not work either. When I run "ftpshut now" it doesn't log
>off existing users, it only prevents new users from logging in.
>
>Is there a way round this too? (apart from killing all active FTP sessions
>individually)
>
>
>Cheers,
>
>--
>Olly Cruickshank


--=====================_352907546==.ALT
Content-Type: text/html; charset="us-ascii"



At 02:55 AM 9/14/2006, Oliver Cruickshank wrote:


Hi,

We're using proftpd 1.3.0 on AIX 5.2.  We receive lots of files
from

trading partners and to avoid polling hundreds of directories we
monitor

the xferlog to see what has been received.


To make sure we don't miss anything, the xferlog file has been converted
to

a FIFO/named pipe( as per


http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-Logging.html

)


Reading the xferlog FIFO is a small Java program.  If nothing is
reading

the FIFO (e.g. if the Java program crashes) we want to make sure that
no

files are processed (we don't want to miss
anything).


So is your FIFO-reader crashing?  Or are you working out your
failure-recovery options?


If the FIFO reader
is not running when a new user logs in, it works fine -

FTP hangs after the log in screen.  However for users already logged
in, if

the FIFO reader crashes then they can still transfer data and no
xferlog

information is captured anywhere.


Well, this _is_ a flaw - not captured anywhere?


To point out why this seems snide (and probably is), I don't use FIFO's
currently.  I do everything using an xferlog _logfile_ reader. 
It passively trails the log, detecting when new entries are added and
acting on that information.


And I _have_ had the reader crash and/or fail to start.  And the
upshot of that was that when I noticed it wasn't running I started it
again, and it resumed from where it left off, processing all the
transfers _since_ the point when it died.  Sometimes that's been a
whole lot of processing all at once, but no one outside the server
noticed.


I guess my bias has always been towards the passive, "outside the
process", type of monitoring.  I don't want processing
(uploads/logins) to stop if something non-FTP-ish has died. 
Something like "what is the least invasive, least coupled way to do
this?"


(Hope this doesn't come across too snide - please consider it an
alternative viewpoint)


is there a way
round this?  (to stop all transfers if the xferlog FIFO

reader has crashed)




Alternatively we could have a program monitor the FIFO reader and do
an

"ftpshut now" to log off all users and prevent new users
logging in.

However this does not work either.  When I run "ftpshut
now" it doesn't log

off existing users, it only prevents new users from logging in.


Is there a way round this too?  (apart from killing all active FTP
sessions

individually)




Cheers,


--

Olly Cruickshank



--=====================_352907546==.ALT--


--===============0541786592==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=...057&dat=121642
--===============0541786592==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html
--===============0541786592==--