vsftpd won't start on SLES 10

I recently installed SLES 10 on an x86 64bit blade server. I then installed vsftpd from the suse cds through network services; however after configuring the vsftpd.conf file, the server fails to start:

# /etc/init.d/vsftpd start
Starting vsftpd startproc: exit status of parent of /usr/sbin/vsftpd: 1
failed

Here is my vsftpd.conf file:

write_enable=YES
dirmessage_enable=YES
local_enable=YES
anonymous_enable=NO
anon_world_readable_only=YES
syslog_enable=YES
connect_from_port_20=YES
pam_service_name=vsftpd
listen=YES
ssl_enable=NO

Any ideas?

Does it produce any useful messages in /var/log? If not, can you increase its' logging level? How does it react to a blank conf file?

In the /var/log/warn file:

zmd: NetworkManagerModule (WARN): Failed to connect to NetworkManager
zmd: Daemon (WARN): Not starting remote web server

The /var/log/rcvsftp.log file is empty.

How do I increase the level of logging? The only options i see in the vsftpd.conf file related to the logging level deal with logging requests/responses, and uploads/downloads.

It appears the error has nothing to do with vsftp at all, it's not even getting that far. Perhaps something is wrong with zmd.

this thread contains some debugging and quick-fix tips for zmd.

zmd appears to be running fine ...

# sudo rczmd stop
Shutting down ZENworks Management Daemon done
# sudo rczmd start
Starting ZENworks Management Daemon done
# sudo rczmd
Checking for ZENworks Management Daemon: running
# /etc/init.d/vsftpd start
Starting vsftpd startproc: exit status of parent of /usr/sbin/vsftpd: 1
failed

The previous network managermodule message didn't appear in the /var/log/warn file this time, so it's probably not related to the vsftpd problem.

Well I "solved" the problem ....

By removing the listen=YES line in the vsftpd.conf file and allowing vsftpd to run as a service instead of standalone it works fine. From the looks of it, SLES is always trying to run it as a service and when I tried to run it standalone it created a conflict between vsftpd and initd that prevented vsftpd from starting .... seems like a bug.