Description of problem: Let's get the ball rolling on this one... http://fedoraproject.org/wiki/Features/SysVtoSystemd https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 561490 [details] Native systemd service for stinit Note that this unit might need another Type= as in either forking or oneshot. I dont own any tape devices hence I could not properly test this...
*** Bug 802681 has been marked as a duplicate of this bug. ***
Dan, any objection to my doing this?
No objection, please just keep in mind it's not a classic initscript, but rather a mean to initialize or setup the tapes.
And thanks in advance.
No worries, I did it as a oneshot, and set RemainAfterExit=yes so that other services that need it will see that it's done and fire at the right time. Thanks!
*** Bug 818961 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > No worries, I did it as a oneshot, and set RemainAfterExit=yes so that other > services that need it will see that it's done and fire at the right time. > Thanks! FYI that will not work... But hey if you want to continue to modify submitted unit files without consulting me feel free to go ahead...
What about that won't work?
You dont order units After Type=oneshot unit(s) that have to wait for that type oneshot unit to finish running something since systemd has no method to reliably detect when what ever got executed in that Type=oneshot unit is done or up and running. Basically it will work if you need to start unit A before unit B but if unit B has to *wait* for unit A to complete something before it gets run it wont work ( Classic race condition and note the above only applies to type oneshot unit ) There are several gotchas that people unfamiliar with migrating legacy sysv init scripts to systemd units are unaware of. So if you have altered or otherwise changed any units that I or others have submitted then please attach and obsolete the submitted units on the bug report so I can review your changes. First and foremost DO NOT BLINDLY PACKAGE YOUR NEW UNIT(S)...
I can't find anything that should wait for this unit in this particular case. It's a very special case completely independent on anything else. Earlier one could set it up with a line in rc.local if there was such a way instead of creating a crippled initscript.
hmm sounds like this could/should all be handled by an udev rule and if that the case and note that I'm no udev expert but you might even get away skipping this unit altogether and simply call <foo before> RUN+="/usr/sbin/stinit" instead of using <foo before> TAG+="systemd", ENV{SYSTEMD_WANTS}="stinit.service" in the udev rule for this component Anyway Type=oneshot unit is the way to go here since there is nothing waiting for it and if doable and relevant you might want to create that udev rule that triggers the starting of that unit if the hw is present. That way users dont have to "start" and enable" the service and it will just work. ( or skip the unit altogether if you can get away with it )