Description of problem: https://fedoraproject.org/wiki/Features/SysVtoSystemd Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 511570 [details] Native systemd service file vsftpd https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd http://fedoraproject.org/wiki/Packaging:Tmpfiles.d
The service file in the comment #1 isn't alternative to SysV initscript because it starts only one daemon. The SysV initscript checks for *.conf files and starts more daemons if necessary. I'm sure this functionality is used (e. g. listening on both IPv?). I've tested service file to call a script. It works but it doesn't differ against SysV initscript. Any tip.
If we need to start more then one instance we switch into using templates and specifier instead for example vsftpd@.service template would look something like this. [Unit] Description=Vsftpd ftp daemon After=syslog.target network.target [Service] Type=oneshot ExecStart=/usr/sbin/vsftpd /etc/vsftpd/%i.conf RemainAfterExit=yes [Install] WantedBy=multi-user.target then you would do.. ln -s vsftpd\@.service vsftpd\@vsftpd.service or ln -s vsftpd\@.service vsftpd\@conf1.service ln -s vsftpd\@.service vsftpd\@conf2.service etc.. see man systemd.units for details on template and specifiers
(In reply to comment #3) > ln -s vsftpd\@.service vsftpd\@conf1.service > ln -s vsftpd\@.service vsftpd\@conf2.service > > etc.. > > see man systemd.units for details on template and specifiers I've thought about this case. But this is quite important change for users. There is not enough to prepare correct config file. The users have to make in addition symbolic link and it will be confusing mainly for current users.
I should mention that the template can be an addon to the submitted service file ( so the submitted one is the "default" then the template for any additional conf files ) Now the other option is to copy the /lib/systemd/system/vsftpd.service and edit that copy which might be less confusion for admins as in.. # cp /lib/systemd/system/vsftpd.service /etc/systemd/system/vsftpd2.service # sed -i 's/vsftpd.conf/vsftpd2.conf/g' /etc/systemd/system/vsftpd2.service # systemctl daemon-reload # systemctl start/stop/status vsftpd2.service etc..
Finally used vsftpd@.service.
Uhum arent you going to build this for F16?
(In reply to comment #7) > Uhum arent you going to build this for F16? yes
Yes, any change from the old and existing behavior of starting multiple instances simultaneously is going to *VERY GREATLY* effect users. The behavior needs to be preserved, and it needs to stay as "automatic" as it was with SysV. Not retaining this is an obvious regression from SysV to SystemD. The obvious use cases for the old behavior: - vsftpd specifically only listens on a single ip per instance. This includes ipv4 and ipv6 addresses, so to provide the same service on both you have to run two instances of vsftpd - vsftpd does not have the idea of "vhosts" outside of attaching to specific ip addresses. This is fine, but when you have a machine providing a great number of ftp sites you can end up with a huge number of config files. - Large mirror sites would (and obviously) do - ISPs are likely to use this - Hosting providers are doing this - etc Let me be blunt: Jóhann's suggestion of having someone manually create symlinks to deal with booting up "separate" services for each config file might work fine for 1, 5 maybe even 10 instances, but you are asking something ridiculous beyond that. Considering that the old behavior is well established and expected is going to cause upgrade issues at the very least, and asking every vsftpd admin with a large number of config files to now also take on the burden of having to manually manage their start-up scripts is nothing but and obvious deficiency in systemd, and it's design. Case in point: I have a number of boxes, most of those boxes have somewhere in the range of 40 or so vsftpd config files. What you are now suggesting is that I have to now manually manage 40 new services start up / shutdown scripts on each of those boxes. And I'm sure me having ~40 or so config files is small in comparison to some users. If the only real "fix" here is for me to do what Jiri originally suggested, write a systemd file that just, basically, calls the old sysv script that seems like systemd has failed in this specific case from the server perspective.
f you are running so many instances you probably would want to put those units in it's own vsftp target and write a script that generates those units for you something like... ### vsftp-unit-generator.sh ### #!/bin/bash for f in $(ls -1 /etc/vsftpd/*.conf | awk -F "." '{print $1}' | awk -F "/" '{print $4}');do echo "Generating systemd units for $f" ln -s /lib/systemd/system/vsftpd\@.service /etc/systemd/system/vsftpd.target.wants/vsftpd\@$f.service > /dev/null 2>&1 done exit 0 You could of course extend the script above to clean up no longer existing units etc as well... Then you would just enable the vsftpd target and all the units get started when the vsftpd target gets loaded...
Is the proposed solution in the comment #10 a part of systemd design? If so the component should be changed to systemd to ask for the design completion.
Comment 10 is just a proposed solution to deal with the fact we have not solved the lack if [Install] section in templates and that issue is being discussed in bug 752774 and probably will be solved soon since Michal Sekletar recently joined Red Hat's systemd team and seems to be working on all bugs we have tag with "fit and finish" ( low priority bugs yet important to improve user experience ) Anyway if you are going to be managing a lot of units the best thing to do is to create a target for those units and change the [Install] section to point to that target and have those units BindTo= that target. That way you only have to do... A) systemctl enable example.target B) systemctl start/restart/reload/stop example.target which will start/restart/reload/stop all the unit that are bound to that target.
Jóhann: that really doesn't solve the base problem here, which is for various services an administrator / user is going to want to spawn N processes, which is what they have become accustomed to, and rely on. However with systemd there is no simple way to say: "For all these config files, just launch an instance of service" Which is fundamentally what `for x in $( ls /etc/<dir>/*.conf );do exec service -c ${x};done` does. vsftpd just happens to be a prime example of this. The configuration files for vsftpd are incredibly specific, to the point where you either get vsftpd running on all interfaces, or you must specify a *SINGLE* ip address within the config file. This means if you have a box with a dozen interfaces, each running ipv4 and ipv6 and you want to provide separate ftp services over those interfaces you need, yes, 24 configuration files. Taking that a step further, lets say you have a cluster of machines, say 8, that all provide vsftp over different ip addresses per box. You are providing both v4 and v6 addresses, and each box, again, has a dozen interfaces you are now looking at 192 configuration files. And as a real world example, kernel.org has systems where there are 32 vsftpd configuration files on it, and 80 separate configuration files for rsync. What systemd is to duplicate the process of "just launch a process for all these configuration files" not force someone to manually write, template and then *ON TOP OF EVERYTHING ELSE* manage each configuration's start/stop/restart/etc scripts, even if it is templated. The only solution I've seen so far, and the one I'm employing, is to have systemd call the old sysV script with the appropriate operation, as systemd is clearly inadequate for solving this problem
(In reply to comment #13) > Jóhann: that really doesn't solve the base problem here, which is for > various services an administrator / user is going to want to spawn N > processes, which is what they have become accustomed to, and rely on. > However with systemd there is no simple way to say: > > "For all these config files, just launch an instance of service" > > Which is fundamentally what > > `for x in $( ls /etc/<dir>/*.conf );do exec service -c ${x};done` > > does. vsftpd just happens to be a prime example of this. The configuration > files for vsftpd are incredibly specific, to the point where you either get > vsftpd running on all interfaces, or you must specify a *SINGLE* ip address > within the config file. This means if you have a box with a dozen > interfaces, each running ipv4 and ipv6 and you want to provide separate ftp > services over those interfaces you need, yes, 24 configuration files. > > Taking that a step further, lets say you have a cluster of machines, say 8, > that all provide vsftp over different ip addresses per box. You are > providing both v4 and v6 addresses, and each box, again, has a dozen > interfaces you are now looking at 192 configuration files. > > And as a real world example, kernel.org has systems where there are 32 > vsftpd configuration files on it, and 80 separate configuration files for > rsync. The above is not systemd problem what the legacy sysv init script did was a bash shell hack to workaround the limitation in the daemon ( which you can duplicate in a type oneshot unit if you so much desire ) hence the daemon would needed to be fixed to parse one or more configuration files at startup and Jiri can answer how much problem it would be for that to be added to vsftpd. > What systemd is to duplicate the process of "just launch a process for all > these configuration files" not force someone to manually write, template and > then *ON TOP OF EVERYTHING ELSE* manage each configuration's > start/stop/restart/etc scripts, even if it is templated. You manage that with units binding to a specific target so when you start/stop etc the *target*, all those units will be started/stop etc. and with that solution you also can manage starting stopping the *units* individually. > The only solution I've seen so far, and the one I'm employing, is to have > systemd call the old sysV script with the appropriate operation, as systemd > is clearly inadequate for solving this problem Because in essence this is not for systemd to solve but should be fixed in the relevant daemon it self.
(In reply to comment #14) > > And as a real world example, kernel.org has systems where there are 32 > > vsftpd configuration files on it, and 80 separate configuration files for > > rsync. > > > The above is not systemd problem what the legacy sysv init script did was a > bash shell hack to workaround the limitation in the daemon ( which you can > duplicate in a type oneshot unit if you so much desire ) hence the daemon > would needed to be fixed to parse one or more configuration files at startup > and Jiri can answer how much problem it would be for that to be added to > vsftpd. Considering that vsftpd only launching one instance per-ip, like I mentioned, is considered a security feature of vsftpd, and one I support in this case, adding it would not happen. Also considering each configuration file defines a separate service for launching a single process reading them all doesn't make any sense. > > What systemd is to duplicate the process of "just launch a process for all > > these configuration files" not force someone to manually write, template and > > then *ON TOP OF EVERYTHING ELSE* manage each configuration's > > start/stop/restart/etc scripts, even if it is templated. > > You manage that with units binding to a specific target so when you > start/stop etc the *target*, all those units will be started/stop etc. and > with that solution you also can manage starting stopping the *units* > individually. Ok maybe I am miss-understanding units entirely, but in my quick reading of the man page, I would need a unit per config file? If that's the case, you are still talking insanity, but maybe I'm just completely miss-understanding unit files? > > The only solution I've seen so far, and the one I'm employing, is to have > > systemd call the old sysV script with the appropriate operation, as systemd > > is clearly inadequate for solving this problem > > Because in essence this is not for systemd to solve but should be fixed in > the relevant daemon it self. Claiming that a specific feature of a specific program, that's commonly used, is broken and should be fixed is not the answer. SystemD is replacing SysV, and needs to take into consideration usage models outside of what the core developers may be seeing. I'm bringing up a specific case here with vsftpd, mainly because I've been bitten by it. It uses configuration files to define isolated individual units, in an effort to maintain security. Considering how many problems ftp had, this was and is still a strong security measure. The old SysV script had a simple feature to launch all of the configuration files from a single script, and this was and continues to be a distinct feature of that script. I'm fine if SystemD lacks the ability to deal with this right now, I'll admit to being an early adopter of systemd from the server perspective. But dismissing this use case as a "daemon should fix itself" is the wrong answer to be taking here, particularly when I'm guessing you don't actually run vsftpd anywhere.
First of all Systemd is spelled Systemd not SystemD Secondly I actually maintained when I worked for the University of Iceland several instances of vsftp and several other services and general administrative stuff on RHEL ( I managed roughly 70 servers + a several vm's there ) In any case templates are what you use to manage multiple instances of the same units and with that sample script snipped I mentioned in comment 10 being called from type one shot unit that would get started before the target is started to have it auto generate that for you at each start up of the target ( or you could run it individually to he necessary symbolic links for the templates to your configuration files ).
Ok, re-reading #10 I think I'm starting to understand your solution better, so I'll apologize for miss-understanding it in the first pass. If I'm correct in my understanding now: What I currently have: - Systemd calls out to the old sysv script that then starts all the processes What you are proposing: - A Systemd unit that finds all the vsftpd.conf files and then generates a systemd unit for each of them based on a template - Once all of those are created systemd would then internally launch all of the processes While your solution would handle the problem, it still seems like a rather glaring deficiency in Systemd. I also don't see it as that much more elegant than making the call out to the old SysV script. I suppose in your case I could turn on/off individual services, but considering I've never had to individually turn them off like that before I'm not really seeing that as an advantage here.
You still fail to see the "deficiency" in the vsftpd daemon itself where it lacks the ability to parses all the configuration files in the relevant directory at startup which is why that bash hack existed in the legacy sysv initscript in the first place. But yeah you got more or less of what I was proposing but you can manage to start/restart/reload/stop all of the units at once by binding the template with with an vsftpd target and then run systemctl start/restart/reload/stop vsftpd.target or you can start/restart/reload/stop services individually by running systemctl start/restart/reload/stop vsftpd
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
vsftpd-3.0.2-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/vsftpd-3.0.2-4.fc19
Package vsftpd-3.0.2-4.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing vsftpd-3.0.2-4.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-14911/vsftpd-3.0.2-4.fc19 then log in and leave karma (feedback).
vsftpd-3.0.2-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.