Baird, Josh | 3 Oct 22:45 2011

[Proftpd-user] ProFTPD Performance stats?

I'm wondering if anyone here is pulling any performance data from
ProFTPD into their NMS or whatnot.  If so, I'm interested in what
metrics you are interested in and how you are obtaining these stats?

Things that I'm thinking of so far:

* Transfers/sec (maybe break down by GET/PUT/etc)
* Logins / Logins/sec
* Throughput

RRD can do math, so total transfers, etc would be acceptable.  We can
use RRD to convert them in to "per/second" datapoints.

Thanks,

Josh

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
ProFTPD Users List   <proftpd-users <at> proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

TJ Saunders | 4 Oct 18:45 2011

Re: [Proftpd-user] Freebsd 9 + mod_mysql


> SIGNAL 14 (SIGALRM)
> process exit, rval = 0
> 
> After about 20-30 seconds just having mod_mysql compiled in on start, 
> proftpd will terminate with the above. If the module is removed, all runs 
> fine.
> 
> I have enabled debugging tracing etc, it just seems the parent process 
> does not seem to like to stay alive after it recieves a SIGALRM.

Which version of proftpd are you running?

TJ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   The split in you is clear.  There is a part of you that knows
   what it should do, and a part that does what it feels like
   doing.

   	-John Cantwell Kiley

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
(Continue reading)

Dan | 4 Oct 19:01 2011

Re: [Proftpd-user] Freebsd 9 + mod_mysql


I have tried on anything from "e" to latest "f" release.
cd /usr/ports/ftp/proftpd; make config
(select mysql)
make install
/usr/local/etc/rc.d/proftpd start

Will terminate after 20-30 seconds even with no connections...
(disable mysql and everything runs fine, which doesn't help me alot)

asterisk:~# uname -a
FreeBSD asterisk.sunsaturn.com 9.0-BETA3 FreeBSD 9.0-BETA3 #1: Thu Sep 29 
08:42:06 CDT 2011 
droot <at> asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL  amd64
asterisk:~#

I realize freebsd in beta 3, but every other software runs perfectly, so 
I'm abit curious as to why this is happening, I suppose could try to set 
SIGALM handler to IGNORE and try it, just strange to begin with.

Dan.

On Tue, 4 Oct 2011, TJ Saunders wrote:

>
>> SIGNAL 14 (SIGALRM)
>> process exit, rval = 0
>>
>> After about 20-30 seconds just having mod_mysql compiled in on start,
>> proftpd will terminate with the above. If the module is removed, all runs
(Continue reading)

TJ Saunders | 4 Oct 19:16 2011

Re: [Proftpd-user] Freebsd 9 + mod_mysql


> I have tried on anything from "e" to latest "f" release.
> cd /usr/ports/ftp/proftpd; make config
> (select mysql)
> make install
> /usr/local/etc/rc.d/proftpd start
> 
> Will terminate after 20-30 seconds even with no connections...
> (disable mysql and everything runs fine, which doesn't help me alot)
> 
> asterisk:~# uname -a
> FreeBSD asterisk.sunsaturn.com 9.0-BETA3 FreeBSD 9.0-BETA3 #1: Thu Sep 29 
> 08:42:06 CDT 2011 
> droot <at> asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL  amd64
> asterisk:~#
> 
> I realize freebsd in beta 3, but every other software runs perfectly, so 
> I'm abit curious as to why this is happening, I suppose could try to set 
> SIGALM handler to IGNORE and try it, just strange to begin with.

Could you add the following to the top of your proftpd.conf, and see what 
gets logged?

  TraceLog /path/to/proftpd-trace.log
  Trace DEFAULT:10 timer:20 sql:20

TJ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(Continue reading)

Dan | 4 Oct 19:22 2011

Re: [Proftpd-user] Freebsd 9 + mod_mysql


Going to include all debug info I could find:

asterisk:~# /usr/local/sbin/proftpd -d 10 -n
  - using TCP receive buffer size of 131072 bytes
  - using TCP send buffer size of 65536 bytes
  - mod_tls/2.4.2: using OpenSSL 0.9.8q 2 Dec 2010
  - mod_sftp/0.9.7: using OpenSSL 0.9.8q 2 Dec 2010
  - retrieved UID 65534 for user 'nobody'
  - retrieved GID 65533 for group 'nogroup'
cappy -
cappy - Config for ProFTPD Default Installation:
cappy - Limit
cappy -  DenyAll
cappy - DefaultServer
cappy - PassivePorts
cappy - Umask
cappy - CommandBufferSize
cappy - UserID
cappy - UserName
cappy - GroupID
cappy - GroupName
cappy - AllowOverwrite
cappy - ROOT PRIVS at mod_delay.c:354
cappy - RELINQUISH PRIVS at mod_delay.c:359
cappy - mod_lang/0.9: binding to text domain 'proftpd' using locale path 
'/usr/local/share/locale'
cappy - mod_lang/0.9: using locale files in '/usr/local/share/locale'
cappy - mod_lang/0.9: added the following supported languages: 
fr_FR.UTF-8, fr_FR, zh_CN.UTF-8, zh_CN, zh_TW.UTF-8, zh_TW, en_US.UTF-8, 
(Continue reading)

TJ Saunders | 4 Oct 19:33 2011

Re: [Proftpd-user] Freebsd 9 + mod_mysql

> Alarm clock: 14
> asterisk:~#
> 
> And from trace log file:
> 
> Sep 30 07:56:45 [73125] <signal:5>: signals blocked
> Sep 30 07:56:45 [73125] <signal:5>: signals unblocked
> Sep 30 07:56:45 [73125] <signal:5>: signals blocked
> Sep 30 07:56:45 [73125] <signal:5>: signals unblocked
> Sep 30 07:56:45 [73125] <fsio:8>: using system lstat() for path 
> '/etc/shutmsg'
> 
> nothing further here when it dies on alarm clock...

Which is utterly bizarre, since proftpd installs signal handlers 
(including for SIGALRM), right after it finishes parsing the config file.  
By default, proftpd sets the "ignore SIGALRM" bit.

The next question then is: is the ports collection there modifying the 
proftpd source somehow?  And is something, outside of proftpd, sending 
SIGARLM to the process?

In the meantime, I'll add explicit logging of errors when installing the 
signal handlers (although I'm pretty sure this isn't the root cause).

TJ

PS I'm assuming that compiling proftpd from the proftpd-1.3.4rc3.tar.bz2 
source code, as distributed from proftpd.org, exhibits the same behavior?  
(If not, that would help indicate that this might be something specific to 
(Continue reading)

Dan | 4 Oct 19:36 2011

Re: [Proftpd-user] Freebsd 9 + mod_mysql


Including trace log, for debugging I am using a completely separate server
with just default freebsd config.

I didn't find any useful info from tracelog , when proftpd dies on ALARM
nothing further is written to trace log.

I don't beleive there is an issue with mysql, mysql is running fine on it, 
as well as other applications, its running latest stable 5.5 from ports.

Dan.

On Tue, 4 Oct 2011, TJ Saunders wrote:

>
>> I have tried on anything from "e" to latest "f" release.
>> cd /usr/ports/ftp/proftpd; make config
>> (select mysql)
>> make install
>> /usr/local/etc/rc.d/proftpd start
>>
>> Will terminate after 20-30 seconds even with no connections...
>> (disable mysql and everything runs fine, which doesn't help me alot)
>>
>> asterisk:~# uname -a
>> FreeBSD asterisk.sunsaturn.com 9.0-BETA3 FreeBSD 9.0-BETA3 #1: Thu Sep 29
>> 08:42:06 CDT 2011
>> droot <at> asterisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL  amd64
>> asterisk:~#
>>
(Continue reading)

Dan | 4 Oct 20:02 2011

Re: [Proftpd-user] Freebsd 9 + mod_mysql


Looked through the port and doesn't seem to be patching it in anyway.
And yes I had tried 1.3.4rc3 as well with same result.

It is entirely possible maybe something in freebsd 9.0 is sending that 
alarm as I beleive beta kernels enable alot of debugging symbols, but I 
beleive I had disabled all I could find in the kernel, but even more 
bizarre then that no other processes die other than proftpd, although I do 
remember one issue of being able to crash system if libnss did not have 
permission to access a certain mysql field, related, hard to tell at this 
point.

The last thing it does below: Sep 30 07:56:45 [73125] <signal:5>: signals 
unblocked: is this removing the ignore SIGALRM bit?

Dan.

On Tue, 4 Oct 2011, TJ Saunders wrote:

>> Alarm clock: 14
>> asterisk:~#
>>
>> And from trace log file:
>>
>> Sep 30 07:56:45 [73125] <signal:5>: signals blocked
>> Sep 30 07:56:45 [73125] <signal:5>: signals unblocked
>> Sep 30 07:56:45 [73125] <signal:5>: signals blocked
>> Sep 30 07:56:45 [73125] <signal:5>: signals unblocked
>> Sep 30 07:56:45 [73125] <fsio:8>: using system lstat() for path
>> '/etc/shutmsg'
(Continue reading)

TJ Saunders | 4 Oct 20:08 2011

Re: [Proftpd-user] Freebsd 9 + mod_mysql


> Looked through the port and doesn't seem to be patching it in anyway.
> And yes I had tried 1.3.4rc3 as well with same result.

Did you try that code from ports, or from the source distribution?

> It is entirely possible maybe something in freebsd 9.0 is sending that 
> alarm as I beleive beta kernels enable alot of debugging symbols, but I 
> beleive I had disabled all I could find in the kernel, but even more 
> bizarre then that no other processes die other than proftpd, although I do 
> remember one issue of being able to crash system if libnss did not have 
> permission to access a certain mysql field, related, hard to tell at this 
> point.
> 
> The last thing it does below: Sep 30 07:56:45 [73125] <signal:5>: signals 
> unblocked: is this removing the ignore SIGALRM bit?

No.  That log line indicates that proftpd is telling the kernel to not 
_block_ signals (among which is SIGALRM), but blocking signals is 
different from having them delivered to the "ignore" signal handler.

TJ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   Come away, O human child!
   to the waters and the wild
   with a faery, hand in hand,
   for the world's more full of weeping
   than you can understand...
(Continue reading)

Dan | 4 Oct 22:13 2011

Re: [Proftpd-user] Freebsd 9 + mod_mysql


This doesn't seem to be a new issue apparently with lack of debugging:
http://forums.proftpd.org/smf/index.php?topic=1771.0;wap2

If you want me to run any patches against source tree help figure this 
out, let me know...

Dan.

On Tue, 4 Oct 2011, TJ Saunders wrote:

>
>> Looked through the port and doesn't seem to be patching it in anyway.
>> And yes I had tried 1.3.4rc3 as well with same result.
>
> Did you try that code from ports, or from the source distribution?
>
>> It is entirely possible maybe something in freebsd 9.0 is sending that
>> alarm as I beleive beta kernels enable alot of debugging symbols, but I
>> beleive I had disabled all I could find in the kernel, but even more
>> bizarre then that no other processes die other than proftpd, although I do
>> remember one issue of being able to crash system if libnss did not have
>> permission to access a certain mysql field, related, hard to tell at this
>> point.
>>
>> The last thing it does below: Sep 30 07:56:45 [73125] <signal:5>: signals
>> unblocked: is this removing the ignore SIGALRM bit?
>
> No.  That log line indicates that proftpd is telling the kernel to not
> _block_ signals (among which is SIGALRM), but blocking signals is
(Continue reading)


Gmane