Bug 789926

Summary: Provide native systemd service
Product: [Fedora] Fedora Reporter: Jóhann B. Guðmundsson <johannbg>
Component: mt-stAssignee: Dan Horák <dan>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: asersen, dan, gwync, mcermak
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-19 18:31:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 751869, 816135    
Attachments:
Description Flags
Native systemd service for stinit none

Description Jóhann B. Guðmundsson 2012-02-13 09:58:45 UTC
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:

Comment 1 Jóhann B. Guðmundsson 2012-02-13 10:01:34 UTC
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...

Comment 2 Dan Horák 2012-04-06 13:59:58 UTC
*** Bug 802681 has been marked as a duplicate of this bug. ***

Comment 3 Gwyn Ciesla 2012-04-18 20:17:16 UTC
Dan, any objection to my doing this?

Comment 4 Dan Horák 2012-04-18 20:28:08 UTC
No objection, please just keep in mind it's not a classic initscript, but rather a mean to initialize or setup the tapes.

Comment 5 Dan Horák 2012-04-18 20:28:33 UTC
And thanks in advance.

Comment 6 Gwyn Ciesla 2012-04-19 18:31:15 UTC
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!

Comment 7 Dan Horák 2012-05-04 13:41:26 UTC
*** Bug 818961 has been marked as a duplicate of this bug. ***

Comment 8 Jóhann B. Guðmundsson 2012-05-16 09:59:58 UTC
(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...

Comment 9 Gwyn Ciesla 2012-05-16 11:59:50 UTC
What about that won't work?

Comment 10 Jóhann B. Guðmundsson 2012-05-17 00:56:03 UTC
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)...

Comment 11 Dan Horák 2012-05-17 06:39:50 UTC
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.

Comment 12 Jóhann B. Guðmundsson 2012-05-17 11:20:41 UTC
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 )