Description of problem: When I boot the system, vsftpd is automatically started. So in the MCC, I unquoted the corresponding "on boot checkbox" and reboot my system. After reboot, if I check in the MCC, the checkbox is still unquoted but the service is still identified as "running" and : # ps -ef|grep vsftpd root 1601 1 0 13:26 ? 00:00:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf # systemctl list-unit-files|grep vsftpd vsftpd.service disabled If I try to connect to the ftp service, it is effectivly available. How can I disable it at system boot ? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
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) => marja11Assignee: bugsquad => brunoSource 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 => RESOLVEDResolution: (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 => REOPENEDResolution: 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 => RESOLVEDResolution: (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 => REOPENEDResolution: 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.
CC: (none) => lewyssmithWhiteboard: MGA5-64-OK => MGA5-64-OK advisory
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
Keywords: (none) => validated_updateWhiteboard: MGA5-64-OK advisory => MGA5-64-OK advisory MGA5-32-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGAA-2017-0001.html