PROFTPD

Howdy,

Hmm, that's an unusual error!

Do you know what kind of Virtual Machine you're using?

Also, what is the output of this command (which you can run by logging into your server as root over SSH):

free -m

Also, what output do you receive if you try running the proftpd command manually:

proftpd -n

We see a lot of strange issues occur on OpenVZ based VPS's... the way it handles memory management can lead to things not working as expected.

That may or may not be the case here :-)

It doesn't usually manifest itself as one command not working such as what you're seeing, it tends to be a bit more random.

If you run the command "cat /proc/user_beancounters", what output do you receive?

-Eric

Howdy,

Yeah, I've never experienced errors such as that on a default install either, except on OpenVZ installs :-)

That user_beancountesr file a list of memory parameters on OpenVZ-based systems.

It looks like the "numproc" has a "failcnt" of 7 -- that means that your provider is limiting the number of processes you can run at once, and on 7 different occasions, a process attempted to start, and was rejected due to the constaints.

Out of curiosity, if you run "proftpd -n" again, does that "failcnt" column for "numproc" go up to 8?

-Eric

Well, that's good, though it's unclear why you're getting that error.

Something strange is going on :-)

You said you checked the logs -- I just wanted to verify that /var/log/proftpd/proftpd.log was one of the logfiles you had looked at.

Also, what output do you get if you run this command:

dmesg | tail -15

That should show if there's any recent kernel errors.

Also, could you attach your /etc/proftpd/proftpd.conf file? I can try using your config on one of my test systems, and see if I'm able to provoke that error.

-Eric

Howdy,

Well, Virtualmin doesn't provide the ProFTPd package, that's pulled down from apt... so there's room for something to go awry if something were unusual about the repository, or during the package installation.

Now, all that is all really unlikely, but you're also the first person to post here about this particular problem, so we're already within the "unlikely" realm of things :-)

I'll test that config and see if any issues stand out.

-Eric

Okay, as you predicted, I'm not seeing anything unusual with your config file. When I place it on my test Ubuntu system, ProFTPd starts up just fine.

I'm running out of ideas as to what to suggest... there's nothing unusual about ProFTPd on a Virtualmin system, it's simply pulled down from the Ubuntu apt repository during Virtualmin installation. No additional configuration is done to that.

So, we should be dealing with an Ubuntu default.

When a default such as that doesn't work, it starts to point to the unusual... corrupt packages, disk errors, memory problems... and other yucky things :-)

Perhaps we ought to verify the package that you have... can you run this command:

dpkg -l 'proftpd*'

That should show what version of ProFTPd you have, as well as where it came from.

Also, the tool "debsums" can help in determining if something somehow became corrupt. You can install that by running this command:

apt-get install debsums

Then, try running it like this:

debsums -ca

When you run that, what output do you get?

-Eric

Hmm what can go wrong, if the only comands and configs during instalation was ... no configuration or anything else to mess up, didnt had a chance yet... :D

I completely understand, and I don't think you did anything wrong :-)

I don't see anything suspicious in your debsums output.

So, I'm fresh out of ideas as to what we can look at on your system.

I think the next step is to talk to your provider, tell them you receive an "Illegal instruction" error anytime you attempt to start your default ProFTPd install, and ask them if they're seeing any memory disk, or other errors related to your installation.

I suppose another alternative is that some security system could be running on your setup that's causing problems... things like SELinux, grsecurity, and the like are capable of causing that.

It shouldn't be a problem on a default Ubuntu installation -- but it's difficult to know what all a provider setup with their distribution images. You may want to ask if they're aware of any security settings that could cause that.

-Eric

Since you're using Ubuntu 10.04 x64, just like me: Do you also get an error for proftpd -v? If not, what version is installed? You can check that in aptitude too.

What output do you get for:

which proftpd
cat \`which proftpd\` | md5sum

Okay, I have the same version and am getting a different checksum. So it's possible the binary (or maybe further files too) are corrupted... Maybe try reinstalling only the ProFTPD package first?

What's your output for uname -a ?

Mine is: Linux lyra 2.6.32-33-server #71-Ubuntu SMP Wed Jul 20 17:42:25 UTC 2011 x86_64 GNU/Linux

Actually, seeing what kind of problems your hoster has with their installation images, I personally would either manually install an Ubuntu if that's possible, or more likely switch to a different hoster.

Having such issues with ProFTPD on a fresh install, I don't really want to know how many things will go wrong over the course of your hosting endeavors, when it comes to more complex things. :)

I'm not too fond in general of this OpenVZ stuff, considering users here report different and odd problems with that like once or twice per week.

We're having the same issue. Proftpd is failing on Ubuntu 10.04 LTS 64 bit with XEN PV enabled.

Not sure why, but this is bad news especially since the XEN version of Ubuntu is now deployed by Citrix XEN server.

How can we get a new "good" build of proftpd?

Thanks

Hm. There was plenty of memory on the server.... To install Ubuntu 10.04.3 LTS 64 bit on Citrix Xen server 6, we are forced to pull the XEN-ready web installer from archive.ubuntu.com ---- so not only it's slow and frustrating, I bet you it's got plenty of non standard packages.

At this moment, we reverted our latest server to a classic Ubuntu 10.04 LTS 64 bit - non para virtualized (so non XEN-ready). And the virtualmin works without a glitch. No issues whatsoever with FTP.

I am out of time today, but I will be trying it again on monday with a fresh install from the XEN repos and the same virtualmin license that we just installed. If all goes well, we will be using that one instead.

I'll keep you posted.

Still fails. We gave the machine 4 GB of RAM. Proftpd is still failing with "Illegal instruction"

We've been posting the issue with Citrix http://forums.citrix.com/thread.jspa?messageID=1594245&#1594245

because it looks like a Xen Server issue more so than a virtualmin issue.

Eric, how can we get another proftpd package installed on the box?

Thanks

Well, you're using the ProFTPd package provided by Ubuntu. If you'd like a different package, you'd need to do one of the following:

1. Compile ProFTPd from source, and use that

2. Find an alternate provider for the ProFTPd package

3. Create your own ProFTPd package from a newer Ubuntu version

I don't really have a recommendation there, as each of those comes with drawbacks... the ideal thing to try would be #3, but that can be a lot of work if you aren't familiar with building .deb packages.

Using #2 is simple, but I don't know of an alternate provider of a ProFTPd package for Ubuntu.

Which leaves #1 -- compiling it all yourself. That can be a bit of work as well, though may be your only option if the other two choices don't work out.

-Eric

Yeah, I figured out as much. If you follow that other thread I posted on Citrix's website you will notice that I just compiled proftpd myself and it works.

But I don't like it: it makes disaster recovery a non-standard process. Bad practice.

This kind of stuff is supposed to work out of the box. the other question it's raising is: what other plain vanilla packages will start failing?

My preference also goes to #3. I actually started the learning process, but it looks like a giant mess to make a debian package.

===========================================

For future reference, here's how we recompiled proftpd:

1) dependencies:

apt-get install make gcc libssl-dev libmysqlclient-dev postgresql-server-dev-8.4 libsqlite3-dev libiodbc2-dev libldap2-dev libwrap0-dev

2) download the latest tarball, extract and get configure command line by typing "proftpd -V" with the older version (if you have it available before)

./configure '--prefix=/usr' '--with-includes=/usr/include/postgresql:/usr/include/mysql' '--mandir=/usr/share/man' '--sysconfdir=/etc/proftpd' '--localstatedir=/var/run' '--libexecdir=/usr/lib/proftpd' '--enable-sendfile' '--enable-facl' '--enable-dso' '--enable-autoshadow' '--enable-ctrls' '--with-modules=mod_readme' '--enable-ipv6' '--enable-nls' '--build' 'x86_64-linux-gnu' '--with-shared=mod_unique_id:mod_site_misc:mod_load:mod_ban:mod_quotatab:mod_sql:mod_sql_mysql:mod_sql_postgres:mod_sql_sqlite:mod_sql_odbc:mod_dynmasq:mod_quotatab_sql:mod_ldap:mod_quotatab_ldap:mod_ratio:mod_tls:mod_rewrite:mod_radius:mod_wrap:mod_wrap2:mod_wrap2_file:mod_wrap2_sql:mod_quotatab_file:mod_quotatab_radius:mod_facl:mod_ctrls_admin:mod_ifsession' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_OPENSSL -DUSE_LDAP_TLS ' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS=' 'CXXFLAGS=-g -O2' 'FFLAGS=-g -O2'

3) compile and install

make && make install

My preference also goes to #3. I actually started the learning process, but it looks like a giant mess to make a debian package.

Oh, don't start from scratch... I would suggest grabbing an existing Ubuntu source package for ProFTPd on a newer version of Ubuntu, and then attempting to compile it. The only things you might need to deal with are to tweak any dependencies if the compile fails.

But you may need to deal up a bit on installing and compiling .deb packages.

This kind of stuff is supposed to work out of the box

I completely agree! And it usually does. The fact that only two people have reported this problem, and it works great for other folks, is quite strange.

You may also want to take this to the Ubuntu community, and see if they have some thoughts. The problem has only been reported on Ubuntu systems, and it's a package provided by their "Universe" repository. It's possible that they might have some thoughts on what's causing this.

-Eric

Thanks for your input. Yeah, I think I should take this up to the Ubuntu community.

What strikes me as strange is that it's only happening in PV mode (para virtualized) on the XEN server, but not when we're in HVM mode (simulated).

Not sure what the difference is. I just know that PV mode exposes more of the processor than HVM and this might be a processor incompatibility. If you look at the compilation options, it's compiled with O2 optimizations. That could be conflicting.

Thanks for the help. Compiling does fix the problem but still... I am worried about other packages failing...

MD