Bug 19647

The problem is that files from the original init system are still packaged.
As a workaround, you can delete /etc/rc.d/init.d/vsftpd

CC: (none) => gm2.asp

Sorry, I fail to see the bug here. Or is it too easy to think that if you don't need vsftpd, it can be uninstalled, and that if you need it, you'll need this daemon to run.

Anyway, assigning to the registered maintainer, who knows better than me :-)

CC: (none) => marja11
Assignee: bugsquad => bruno
Source RPM: (none) => vsftpd

@Marja van Waes
My problem is to start/stop vsftpd when I need/don't need it. Not to install/uninstall it when I have or not a file to transfer.
Would you install/uninstall firefox when you have or not to go to the internet ?

@Arne Spiegelhauer
Ok, it works

I think the problem mentioned is that due to SysV init scripts still present in the package the service is activated despite systemctl is used to not activate it.

So I think the best approach is now to remove this /etc/rc.d/init.d/vsftpd from the package if it's not mandatory anymore.

I'll update the package accordingly

Status: NEW => ASSIGNED

Now fixed in both cauldron and 5.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

(In reply to Bruno Cornec from comment #5)
> Now fixed in both cauldron and 5.

If fixed in Mageia 5, shouldn't you submit to updates_testing then assign to QA for update validation?

I submitted to updates_testing but forgot to assign sorry

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)
QA Contact: (none) => qa-bugs

(In reply to Bruno Cornec from comment #7)
> I submitted to updates_testing but forgot to assign sorry

Thanks. Please also provide the list of packages and an advisory and we're good to go :)

See https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29

I uninstalled vsftpd-3.0.2-4.1.mga4.x86_64 and installed vsftpd-3.0.2-8.mga5.x86_64 (see /var/log/messages below):

Oct 28 16:35:10 localhost [RPM][4353]: erase vsftpd-3.0.2-4.1.mga4.x86_64: success
Oct 28 16:35:10 localhost systemd[1]: Unknown serialization item 'subscribed=:1.0'
Oct 28 16:35:10 localhost [RPM][4353]: Transaction ID 5813621d finished: 0
Oct 28 16:35:10 localhost perl[4353]: opening the RPM database
Oct 28 16:35:13 localhost perl[4353]: opening the RPM database
Oct 28 16:35:41 localhost perl[4353]: opening the RPM database
Oct 28 16:35:41 localhost perl[4353]: opening the RPM database
Oct 28 16:35:42 localhost perl[4353]: opening the RPM database
Oct 28 16:35:48 localhost drakrpm: transaction on / (remove=0, install=0, upgrade=1)
Oct 28 16:35:48 localhost [RPM][4353]: Transaction ID 58136244 started
Oct 28 16:35:48 localhost avahi-daemon[750]: Files changed, reloading.
Oct 28 16:35:48 localhost avahi-daemon[750]: Loading service file /services/vsftpd.service.
Oct 28 16:35:48 localhost avahi-daemon[750]: Files changed, reloading.
Oct 28 16:35:49 localhost systemd[1]: Unknown serialization item 'subscribed=:1.0'
Oct 28 16:35:49 localhost avahi-daemon[750]: Service "Ftp server on linux" (/services/vsftpd.service) successfully established.
Oct 28 16:35:49 localhost systemd[1]: Unknown serialization item 'subscribed=:1.0'
Oct 28 16:35:49 localhost [RPM][4353]: install vsftpd-3.0.2-8.mga5.x86_64: success
Oct 28 16:35:49 localhost systemd[1]: Unknown serialization item 'subscribed=:1.0'
Oct 28 16:35:49 localhost [RPM][4353]: Transaction ID 58136244 finished: 0
Oct 28 16:36:54 localhost perl[4353]: moved file /etc/vsftpd/user_list.rpmsave to /etc/vsftpd/user_list
Oct 28 16:37:18 localhost perl[4353]: moved file /etc/vsftpd/vsftpd.conf.rpmsave to /etc/vsftpd/vsftpd.conf
Oct 28 16:37:22 localhost perl[4353]: opening the RPM database
Oct 28 16:37:51 localhost perl[4353]: ### Program is exiting ###

I unquoted the "on boot checkbox".

I reboot :

At start up, vsftpd is still alive :
# ps -ef|grep vsftpd
root      1550     1  0 16:56 ?        00:00:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
root      2294  2254  0 16:57 pts/0    00:00:00 grep --color vsftpd

and vsftpd.service is disabled :
# systemctl list-unit-files|grep vsftpd
vsftpd.service                             disabled

and vsftpd system V daemon is present in /etc/rc.d/init.d/
# ls /etc/rc.d/init.d/vsftpd
/etc/rc.d/init.d/vsftpd*

You should use -9 packages which are under updates_testing, not -8.

Package to be tested: vsftpd-3.0.2-9.mga5.x86_64.rpm source: vsftpd-3.0.2-9.mga5.src.rpm

Advisory pushed.

I could not find it in the repositories (core updates, core updates testing)

http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/5/x86_64/media/core/updates_testing/vsftpd-3.0.2-9.mga5.x86_64.rpm

vsftpd-3.0.2-9.mga5.x86_64.rpm is OK

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

@ Christian: The procedure for update candidates is that they are tested by the QA team, then validated, then pushed to core/updates and only then should the bug be closed :)

On the other hand, when you test an update candidate you can add a marker to the whiteboard to indicate what test was done: MGA5-32-OK or MGA5-64-OK (in your case the latter, as I just added).

Thanks for testing :)

@ Bruno: We still need an advisory, see comment 8.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)
Whiteboard: (none) => MGA5-64-OK

Think I forgot to reassign to QA after having done the adv.

Assignee: bruno => qa-bugs

(In reply to Bruno Cornec from comment #16)
> Think I forgot to reassign to QA after having done the adv.

If you upload the advisory yourself, as stated already in other bug reports, you should also copy it here for the benefits of the QA team. The QA testers don't read svn logs :)

Also you should add `advisory` to the Whiteboard.

Testing this on i586 vbox in KDE4

$ sudo urpmi vsftpd
Package vsftpd-3.0.2-8.mga5.i586 is already installed
Started the vsftpd service with mcc and unchecked "on boot" then rebooted the vbox.

On boot still unchecked but the service was running.  This is true even if the service is stopped
before the reboot.
$ ps -ef | grep vsft
root      1387     1  0 15:00 ?        00:00:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
$ sudo systemctl list-unit-files | grep vsftpd
vsftpd.service                          disabled
$ systemctl status vsftpd.service
â vsftpd.service - Vsftpd ftp daemon
   Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled)
   Active: active (running) since Mon 2017-01-09 15:00:54 GMT; 12min ago
  Process: 1384 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
 Main PID: 1387 (vsftpd)
   CGroup: /system.slice/vsftpd.service
           ââ1387 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf

After the update, with 'On boot' disabled:

$ systemctl status vsftpd
â vsftpd.service - Vsftpd ftp daemon
   Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled)
   Active: inactive (dead)

Could be started again using systemctl.  OK for 32-bit systems.

CC: (none) => tarazed25

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGAA-2017-0001.html

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED