Some Good Notes

From -- footnote is thoughtful
Re: vsftpd won't restart
Originally Posted by jmirick
I had all of these problems, including the "could not bind" response, and I pass on my experience:

First, the syntax "vsftpd restart" is not allowed in talking to vsftpd, it takes this to mean "start me with an override configuration file called 'restart'". And, if you just try to enter "vsftpd" it takes that as a start command, and says, "I can't, somebody else owns that port" which is correct since an existing instance owns it, its already running (as you note).

Second, for all you long-term Unix personages, remember that Ubuntu is very highly GUI-oriented and so the way to shut off a major service (like Ubuntu, or Apache, or whatever) is to use the System | Administration | Services menu rather than the command line. I can't figure out how you do anything at all with vsftpd at the command line except start it, but that's OK because checking / unchecking the box in Services does it just fine.
Some good guesses there, but all way off the mark...

The vsftpd script in /etc/init.d accepts start, stop, restart and reload as valid options - they each do distinct things.

The reason you're getting some odd errors when trying to execute 'vsftpd restart' whilst in /etc/init.d/ is nothing to do with it trying to read in a config file called 'restart' it is because the current directory is not in your PATH - this is by design[Footnote 1]. Thus, when you're typing 'vsftpd' it's actually trying to execute /usr/sbin/vsftpd (because /usr/sbin/ is in root's PATH).

Hence, to execute the script properly do one of the following:

1) If you're already in /etc/init.d/ enter ./vsftpd <option i.e. start|stop|restart|reload>

or 2) If you're elsewhere enter /etc/init.d/vsftpd <option>

This applies to all scripts and executables - if you're in the parent directory you need to prefix it by ./


P.S. I won't even comment on your claim that services under Ubuntu need the GUI to control them - that really is nonsense..!

[1] If you're interested why, it is thus: Suppose someone left bits of malicious executable code around and named them the same as common system commands. Then, as a user with sudo privileges, you happened to be in a directory containing (unknowingly) one of these executables - called 'ls' for example. If you wanted to see the directory listing you'd type 'ls'... however the malicious code would instead get run. Thus, by removing the current directory from your PATH this risk is mitigated somewhat because you have to explicitly request the executing of the 'ls' in the current directory by either calling ./ls or /full/path/to/ls - 'ls' alone would not suffice (it would run the 'proper' system 'ls').
Last edited by MJN; January 24th, 2006 at 04:35 AM..