vsftp fail to start

ken_yap · May 25, 2011, 1:41am

I agree, vsftpd can work in either mode depending on a conf file setting and that’s probably flyspring’s problem. But you are now talking about a different issue. I replied because in your post you implied that /etc/init.d/vsftpd was somehow not the right way and proposed two alternate ways of invoking /etc/init.d/vsftpd which are actually equivalent and in fact less official.

In general rcfoo and service foo are equivalent to /etc/init.d/foo.

For the record, I use rcfoo when I remember because it’s easy with command completion. I sometimes forget to use rc because of the other systems I have to manage.

martin_helm · May 25, 2011, 1:43am

Carlos E. R. wrote:
> Correction. Without it, it is intended to run via xinet. That is what the
> comments say:
>
>


>
> # Set listen=YES if you want vsftpd to run standalone
> #
> # listen=YES
>
>

>
>
> I understand that “standalone” means as service daemon.
>
Now we are on the same track

robin_listas · May 25, 2011, 1:50am

On 2011-05-25 01:33, martin_helm wrote:

> This is what I tested (the file from the jhiatt08) with and without
> listen=YES via rcvsftpd and /etc/ini.t/vsftpd (which both are identical in
> openSUSE), without it gives the message the OP showed us and with the
> setting it starts.

Because his configuration is meant for use via xinet. That is what I’m
trying to say all the time.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

flyspring · May 25, 2011, 12:45pm

robin_listas:

su -
rcvsftpd restart

or

service vsftpd restart
(This is not Ubuntu).

And make sure you have:
syslog_enable=YES
in the config. Otherwise, you have to figure out where it logs to.

However, unless you have configured vsftpd to start this way, by default in
openSUSE vsftpd is started via xinetd, not via startup script.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

Running " rcvsftpd restart " or " service vsftpd restart " get the same results:

Shutting down vsftpd done
Starting vsftpd startproc: exit status of parent of /usr/sbin/vsftpd: 1
failed
I checked /etc/vsftpd.conf and it has the code : syslog_enable=YES

flyspring · May 25, 2011, 12:49pm

martin_helm:

Carlos E. R. wrote:

> The correct procedure would be:
>
>


&gt; su -
&gt; rcvsftpd restart
&gt;
no doubt this is correct but without any kind of listen=YES in the conf file
it will fail also.

--
PC: oS 11.3 64 bit | Intel Core2 Quad Q8300@2.50GHz | KDE 4.6.3 | GeForce
9600 GT | 4GB Ram
Eee PC 1201n: oS 11.4 64 bit | Intel Atom 330@1.60GHz | KDE 4.6.0 | nVidia
ION | 3GB Ram

I set listen=YES, but no improvement.

flyspring · May 25, 2011, 12:52pm

Installed vsftpd from Yast. I didn’t edit the vsftpd.conf file manually.

martin_helm · May 25, 2011, 1:46pm

Seeing your other post that you used yast to configure ftp you have now a
complete mess.
Why?
Answer: yast takes the suse way to configure vsftp for working via xinet and
you are supposed to also use in yast the xinet configuration. It is not
compatible with running it via inet.d scripts.

It may simply fail because you have now a mixture of somehow xinet activated
but trying to start vsftpd via inet.d scripts or whatever else.

Can you describe precisely step by step what you have done exactly, how and
when and in which order? We can not see over your shoulder.

martin_helm · May 25, 2011, 1:49pm

martin_helm wrote:

> Seeing your other post that you used yast to configure ftp you have now a
> complete mess.
> Why?
> Answer: yast takes the suse way to configure vsftp for working via xinet
> and you are supposed to also use in yast the xinet configuration. It is
> not compatible with running it via inet.d scripts.
>
> It may simply fail because you have now a mixture of somehow xinet
> activated but trying to start vsftpd via inet.d scripts or whatever else.
>
> Can you describe precisely step by step what you have done exactly, how
> and when and in which order? We can not see over your shoulder.
>
Let me add that it is absolutely no problem to run vsftpd via
/etc/init.d/vsftpd if you want that and if it is configured the correct way
to work with it as I tested yesterday (I do not use that myself but use the
xinet approach, because I like to configure it via yast, but I made the
changes to see if it works as expected and it does but one has to do some
mouse clicks and change the conf file).

jthiatt08 · May 25, 2011, 3:50pm

flyspring:

here:

write_enable=YES
dirmessage_enable=YES
nopriv_user=ftpsecure
local_enable=YES
chroot_local_user=YES
anonymous_enable=NO
anon_world_readable_only=YES
syslog_enable=YES
connect_from_port_20=YES
ascii_upload_enable=YES
pam_service_name=vsftpd
ssl_enable=NO
pasv_min_port=30000
pasv_max_port=30100

Add the following to your vsftpd.conf file and then restart the daemon.


listen_ipv6=YES

Good luck,
Hiatt

robin_listas · May 25, 2011, 5:17pm

On 2011-05-25 13:06, flyspring wrote:

> Installed vsftpd from Yast. I didn’t edit the vsftpd.conf file
> manually.

You do not need to start vsftpd service. Simply try to connect to it - that
is what “started from xinet” means. It is started when needed, not on boot.

You decide what method to use, but the configuration you posted is as I
described above.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

robin_listas · May 25, 2011, 9:03pm

On 2011-05-25 02:06, ken yap wrote:

> In general rcfoo and service foo are equivalent to /etc/init.d/foo.

The thing is, if there is no “rcfoo”, you should not try /etc/init.d/foo
directly, it is not intended to be run that way. It happens with some
services that are split across several script, like earlyfoo.

> For the record, I use rcfoo when I remember because it’s easy with
> command completion. I sometimes forget to use rc because of the other
> systems I have to manage.

Yes, rc[tab][tab] and you see the name.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

ken_yap · May 26, 2011, 12:15am

I’ve never heard of a rule like that. Certainly there are scripts in init.d that are not meant to be run directly by the user but whether you should or should not run the script depends on knowledge of what the script does. Can you show me where YaST or rpm sets it up so the symlink rcvsftpd is removed when xinetd mode is chosen and puts it back when standalone server mode is chosen? I don’t think you can. I think the symlink exists all the time.

It would be more logical from the script writer’s point of view, if such a check is desired, to make /etc/init.d/vsftpd read vsftpd.conf and warn if it is in xinetd mode and not run the daemon. Or just let vsftpd throw an error.

robin_listas · May 26, 2011, 3:08am

On 2011-05-26 00:36, ken yap wrote:
>
> robin_listas;2344764 Wrote:
>> On 2011-05-25 02:06, ken yap wrote:
>>
>>> In general rcfoo and service foo are equivalent to /etc/init.d/foo.
>>
>> The thing is, if there is no “rcfoo”, you should not try
>> /etc/init.d/foo directly, it is not intended to be run that way. It happens with some
>> services that are split across several script, like earlyfoo.
>
> I’ve never heard of a rule like that. Certainly there are scripts in
> init.d that are not meant to be run directly by the user but whether you
> should or should not run the script depends on knowledge of what the
> script does. Can you show me where YaST or rpm sets it up so the symlink
> rcvsftpd is removed when xinetd mode is chosen and puts it back when
> standalone server mode is chosen? I don’t think you can. I think the
> symlink exists all the time.

/etc/init.d/SuSEfirewall2_init
/etc/init.d/SuSEfirewall2_setup

Those two have no rc-link. Running them is an error, one you do not make if
you try to run “rcSuSEfirewall2_init”, because it does not exist.

That is what I mean, not that rcvsftpd is removed when the intention is to
run from xinet. It would be a nice feature, though, or that the script
printed a meaningful message.

> It would be more logical from the script writer’s point of view, if
> such a check is desired, to make /etc/init.d/vsftpd read vsftpd.conf and
> warn if it is in xinetd mode and not run the daemon. Or just let vsftpd
> throw an error.

Actually, vsftpd throws an error, you can see it in one of the posts. But
the script hides it. Unfortunately.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

ken_yap · May 26, 2011, 3:57am

Right, so coming back to your post about not using /etc/init.d/vsftpd, it is no different from rcvsftpd or service vsftpd really. So that little bit about “this is not Ubuntu” is a red herring.

Bear in mind that the people who use either rc or init.d are CLI users. It really would make little difference to them if they couldn’t find rcvsftpd, they would go and try /etc/init.d/vsftpd next. If there is to be a check, it should be in the script, not in creating or destroying the symlink. If the devs only put the check for xinetd or standalone in YaST, I can understand that, it’s the job of YaST to handhold.

robin_listas · May 26, 2011, 11:20am

On 2011-05-26 04:06, ken yap wrote:
>
> robin_listas;2344909 Wrote:

> Right, so coming back to your post about not using /etc/init.d/vsftpd,
> it is no different from rcvsftpd or service vsftpd really. So that
> little bit about “this is not Ubuntu” is a red herring.

No, that bit is for not using sudo. I don’t like it. I’m afraid it doesn’t
set the full root’s environment and that /might/ cause problems.

> Bear in mind that the people who use either rc or init.d are CLI users.

Like me

> It really would make little difference to them if they couldn’t find
> rcvsftpd, they would go and try /etc/init.d/vsftpd next. If there is to
> be a check, it should be in the script, not in creating or destroying
> the symlink. If the devs only put the check for xinetd or standalone in
> YaST, I can understand that, it’s the job of YaST to handhold.

If there is no rc, it should not be run >:-)
Don’t search for it elsewhere.

I have not said anything about a check for creating the symlink in the
script. The link is created by the SUSE devs when the script can be called
manually, and not if you should not run it manually.

It would be nice, though, that the link be removed when the service is
intended to run from xinet. Perhaps. Or more feasible, put a proper message.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

ken_yap · May 26, 2011, 1:09pm

Nah, don’t be afraid, feel the fear and just do it anyway. Show the machine who is the master.

Believe me it works, I do it and it works for me and if you are in the same universe it will work for you too.

If you want to be sure to get root’s environment, use -i with sudo.

It would be nice, though, that the link be removed when the service is
intended to run from xinet. Perhaps. Or more feasible, put a proper message.

It would be better for it to check vsftpd.conf and say this service should be started from xinetd if that’s the case. That way it doesn’t matter where you call the script from. That includes the case of service vsftpd.

But then I know my machine and even though it can beat me at chess, I can beat it at Thai boxing anytime I like so I’m not fussed about this.

Perhaps it should be an openFATE request.

robin_listas · May 26, 2011, 3:33pm

On 2011-05-26 13:36, ken yap wrote:
> It would be better for it to check vsftpd.conf and say this service
> should be started from xinetd if that’s the case. That way it doesn’t
> matter where you call the script from. That includes the case of service
> vsftpd.

The daemon does that check and prints a message - but the script eats it.
When the OP did “sudo /usr/sbin/vsftpd”, the response was:


“500 OOPS: vsftpd: not configured for standalone, must be started from
inetd”

which is very clear. Why is not that message printed when you use the
service script? That would be the bug.

The calling line in the script is:


/sbin/startproc -l /var/log/rcvsftp.log $VSFTPD_BIN

The manual for startproc says:

-l log_file
Redirect the process standard output and standard error
to the file log_file.

So the error should have been printed to /var/log/rcvsftp.log. However, I
have tried to start the service, I get the error:


Starting vsftpd startproc:  exit status of parent of /usr/sbin/vsftpd: 1

the log file is created, but it is empty. Somehow the error does not print.
Indeed, if you call “vsftpd” it does print the correct message, so
startproc interferes.

I could create a bug on this, but I’m still running 11.2 in this machine,
so I can’t. Yet, at least.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)