Hi,
Ran into this fun one today. bric_ftpd would die with this error in the
ftp log when listing a directory:
Can't locate DateTime/TimeZone/OlsonDB/Rule.pm in @INC
however the file exists and was in INC.
Turned out to be a wild goose chase, and the problem was the proc was
hitting system limits. grsec logging showed:
> [66201.702613] grsec: From 208.70.247.145: denied resource overstep by
> requesting 56958752 for RLIMIT_DATA against limit 16777216 for
> bricolage2/bin/bric_ftpd[bric_ftpd:29706] uid/euid:1001/1001
> gid/egid:442/442, parent /usr/sbin/xinetd[xinetd:29694] uid/euid:0/0
> gid/egid:0/0
and:
> [66218.846862] grsec: From 208.70.247.145: denied resource overstep by
> requesting 20 for RLIMIT_NOFILE against limit 20 for
> bricolage2/bin/bric_ftpd[bric_ftpd:29706] uid/euid:1001/1001
> gid/egid:442/442, parent /usr/sbin/xinetd[xinetd:29694] uid/euid:0/0
> gid/egid:0/0
After trying to track down what on earth was setting the limits, it
turns out Net::FTPServer does!
> # Install per-process limits.
> $self->log ("info", "in process limits stage") if $self->{debug};
>
> $r = $self->process_limits_hook;
> exit if $r == -1;
>
> # Perform normal per-process limits.
> if ($r == 0)
> {
> my $limit = 1024 * ($self->config ("limit memory") || 16384);
> $self->_set_rlimit ("RLIMIT_DATA", $limit) if $limit >= 0;
>
> $limit = $self->config ("limit nr processes") || 10;
> $self->_set_rlimit ("RLIMIT_NPROC", $limit) if $limit >= 0;
>
> $limit = $self->config ("limit nr files") || 20;
> $self->_set_rlimit ("RLIMIT_NOFILE", $limit) if $limit >= 0;
> }
Since Bric doesn't pass anything in, we end up with some default limits
of 20 file handles, 10 processes, and 16 mb for the data segment.
Not sure why this install is triggering this limit, it's a bric 2
upgrade, so maybe something there.
As a "fix", we added:
> sub process_limits_hook {
> return 1;
> }
at the end of lib/Bric/Util/FTP/Server.pm. This overrides Net::FTPServer
and ensures no limits are set.
I think this is the cause to this bug here:
http://www.gossamer-threads.com/lists/bricolage/bugs/31702#31702
Thoughts?
Cheers,
Alex
--
Alex Krohn <alex@gossamer-threads.com>
Ran into this fun one today. bric_ftpd would die with this error in the
ftp log when listing a directory:
Can't locate DateTime/TimeZone/OlsonDB/Rule.pm in @INC
however the file exists and was in INC.
Turned out to be a wild goose chase, and the problem was the proc was
hitting system limits. grsec logging showed:
> [66201.702613] grsec: From 208.70.247.145: denied resource overstep by
> requesting 56958752 for RLIMIT_DATA against limit 16777216 for
> bricolage2/bin/bric_ftpd[bric_ftpd:29706] uid/euid:1001/1001
> gid/egid:442/442, parent /usr/sbin/xinetd[xinetd:29694] uid/euid:0/0
> gid/egid:0/0
and:
> [66218.846862] grsec: From 208.70.247.145: denied resource overstep by
> requesting 20 for RLIMIT_NOFILE against limit 20 for
> bricolage2/bin/bric_ftpd[bric_ftpd:29706] uid/euid:1001/1001
> gid/egid:442/442, parent /usr/sbin/xinetd[xinetd:29694] uid/euid:0/0
> gid/egid:0/0
After trying to track down what on earth was setting the limits, it
turns out Net::FTPServer does!
> # Install per-process limits.
> $self->log ("info", "in process limits stage") if $self->{debug};
>
> $r = $self->process_limits_hook;
> exit if $r == -1;
>
> # Perform normal per-process limits.
> if ($r == 0)
> {
> my $limit = 1024 * ($self->config ("limit memory") || 16384);
> $self->_set_rlimit ("RLIMIT_DATA", $limit) if $limit >= 0;
>
> $limit = $self->config ("limit nr processes") || 10;
> $self->_set_rlimit ("RLIMIT_NPROC", $limit) if $limit >= 0;
>
> $limit = $self->config ("limit nr files") || 20;
> $self->_set_rlimit ("RLIMIT_NOFILE", $limit) if $limit >= 0;
> }
Since Bric doesn't pass anything in, we end up with some default limits
of 20 file handles, 10 processes, and 16 mb for the data segment.
Not sure why this install is triggering this limit, it's a bric 2
upgrade, so maybe something there.
As a "fix", we added:
> sub process_limits_hook {
> return 1;
> }
at the end of lib/Bric/Util/FTP/Server.pm. This overrides Net::FTPServer
and ensures no limits are set.
I think this is the cause to this bug here:
http://www.gossamer-threads.com/lists/bricolage/bugs/31702#31702
Thoughts?
Cheers,
Alex
--
Alex Krohn <alex@gossamer-threads.com>