Bug 789926 - Provide native systemd service
Summary: Provide native systemd service
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mt-st
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Horák
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 802681 818961 (view as bug list)
Depends On:
Blocks: 751869 816135
TreeView+ depends on / blocked
 
Reported: 2012-02-13 09:58 UTC by Jóhann B. Guðmundsson
Modified: 2012-05-17 11:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-19 18:31:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Native systemd service for stinit (119 bytes, text/plain)
2012-02-13 10:01 UTC, Jóhann B. Guðmundsson
no flags Details

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 )


Note You need to log in before you can comment on or make changes to this bug.