Bug 1443055

Huh it looks that vsftpd is writing to STDIN

[0 root@qeos-193 test]# /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf 
500 OOPS: unrecognised variable in config file: foo
[0 root@qeos-193 test]# /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf 0>/dev/null
[0 root@qeos-193 test]# 

If you want a workaround then you can use something like this:
[0 root@qeos-193 test]# cat /etc/systemd/system/vsftpd.service
[Unit]
Description=Vsftpd ftp daemon
After=network.target

[Service]
Type=forking
ExecStart=/bin/bash -c "/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf 0>&1"

[Install]
WantedBy=multi-user.target


and then:

[0 root@qeos-193 test]# journalctl -u vsftpd | grep variable
dub 18 09:11:24 qeos-193.lab.eng.rdu2.redhat.com bash[15346]: 500 OOPS: unrecognised variable in config file: foo

Well in vsftpd, the file descriptor 0 is supposed to be the command socket as defined here:
https://pagure.io/vsftpd/blob/master/f/defs.h#_6

And the error is written into this fd as you can see here:
https://pagure.io/vsftpd/blob/master/f/utility.c#_46

Unfortunately right after start-up the fd 0 is still STDIN.

Is there any way to enhance the service file to not use bash for executing vsftpd, but rather use some systemd functionality?

There is no way that I'd be aware of. I think we need to fix this in vsftpd if we really want to change it.

I was also discussing this with a systemd maintainer and he also said, that systemd does not have any feature to handle this case and vsftpd should be fixed instead.

I think we could solve this in vsftpd simply by redefining VSFTP_COMMAND_FD to 1.
https://pagure.io/vsftpd/blob/master/f/defs.h#_6

This should work both in standalone mode and in the mode where vsftpd is run from inetd.

In standalone mode the file descriptor 1 points to stdout during the time when configuration is loaded, so any errors written to it will be picked up by systemd. After that, file descriptor 1 points to /dev/null and after a connection is established, the connection file descriptor is duplicated to FD 1, as well as to FD 0 and 2, so it doesn't matter which FD we use:
https://pagure.io/vsftpd/blob/master/f/standalone.c#_226-237

When run from inetd, vsftpd should have the connection FD duplicated to both FD 0 and 1, so there should be no regressions in this case either. However the error will not be sent to syslog, but to the connected client. We have a separate RFE to get these errors, which are sent over the connection, to syslog as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1318198

I also tested it and it seems to work.

Created attachment 1417556 [details]
patch

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:3037