Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 789697 - Provide native systemd service
Provide native systemd service
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: iodine (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Pavel Alexeev
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 751869
  Show dependency treegraph
 
Reported: 2012-02-12 07:05 EST by Jóhann B. Guðmundsson
Modified: 2012-05-03 03:19 EDT (History)
3 users (show)

See Also:
Fixed In Version: iodine-0.6.0-0.rc1.9.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-02 00:43:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Native systemd service for iondine client (191 bytes, text/plain)
2012-02-12 07:06 EST, Jóhann B. Guðmundsson
no flags Details
Native systemd service for iondine server (191 bytes, text/plain)
2012-02-12 07:07 EST, Jóhann B. Guðmundsson
no flags Details

  None (edit)
Description Jóhann B. Guðmundsson 2012-02-12 07:05:47 EST
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-12 07:06:30 EST
Created attachment 561208 [details]
Native systemd service for iondine client
Comment 2 Jóhann B. Guðmundsson 2012-02-12 07:07:02 EST
Created attachment 561209 [details]
Native systemd service for iondine server
Comment 3 Pavel Alexeev 2012-02-18 07:43:14 EST
SysV script got settings from /etc/sysconfig/iodine-{cleint,server} files. You provide very simple systemd services with hardcoded parameters. How it intended to be customized?
Comment 4 Jóhann B. Guðmundsson 2012-02-18 09:46:57 EST
(In reply to comment #3)
> SysV script got settings from /etc/sysconfig/iodine-{cleint,server} files. You
> provide very simple systemd services with hardcoded parameters. How it intended
> to be customized?

/etc/sysconfig/foo Environment files are in a sense obsolete and Fedora/Red Hat distribution specific thus wont fly with upstream when you submit the units there.

The future and distribution agnostic way to customize units for daemons that do not support parsing a config file is this.

http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F
Comment 5 Pavel Alexeev 2012-02-19 13:05:59 EST
(In reply to comment #4)
> (In reply to comment #3)
> /etc/sysconfig/foo Environment files are in a sense obsolete and Fedora/Red Hat
> distribution specific thus wont fly with upstream when you submit the units
> there.
IIRC Systemd also used only in Fedora now, so it is Fedora specific and for what it for upstream author I couldn't understand.

> The future and distribution agnostic way to customize units for daemons that do
> not support parsing a config file is this.
Iodine does not use any config AFAIK. So, should I treat systemd units as config files and provide your units do not wait it may be started without modifications by users??
Comment 6 Jóhann B. Guðmundsson 2012-02-19 13:35:59 EST
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > /etc/sysconfig/foo Environment files are in a sense obsolete and Fedora/Red Hat
> > distribution specific thus wont fly with upstream when you submit the units
> > there.
> IIRC Systemd also used only in Fedora now, so it is Fedora specific and for
> what it for upstream author I couldn't understand.

Who feed you that information that systemd was only in Fedora? 

That individual needs to be corrected. 

You can enlighten his ignorance and just point him to http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac and read line 419 ( 
case $with_distro in ) and higher which contains a list of distribution that either currently are shipping systemd as a default or they are shipping it along their current implementation as an alternative or are working on shipping systemd.

> 
> > The future and distribution agnostic way to customize units for daemons that do
> > not support parsing a config file is this.
> Iodine does not use any config AFAIK. So, should I treat systemd units as
> config files and provide your units do not wait it may be started without
> modifications by users??

Sorry not following you here. 

Ship the units. drop the /etc/sysconfig/foo files and point users to use http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F instead.
Comment 7 Pavel Alexeev 2012-02-19 14:18:38 EST
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > /etc/sysconfig/foo Environment files are in a sense obsolete and Fedora/Red Hat
> > > distribution specific thus wont fly with upstream when you submit the units
> > > there.
> > IIRC Systemd also used only in Fedora now, so it is Fedora specific and for
> > what it for upstream author I couldn't understand.
> 
> Who feed you that information that systemd was only in Fedora? 
> 
> That individual needs to be corrected. 
> 
> You can enlighten his ignorance and just point him to
> http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac and read line 419
> ( 
> case $with_distro in ) and higher which contains a list of distribution that
> either currently are shipping systemd as a default or they are shipping it
> along their current implementation as an alternative or are working on shipping
> systemd.

No. It is just list of sustems on which it may be configured and built (configure script support it). Nothing more!

According to Ubuntu WIKI f.e. ( https://wiki.ubuntu.com/systemd#Warning.21_Experimental_code ) it is experimental code (on Jan 2012) and does not supported.

> > 
> > > The future and distribution agnostic way to customize units for daemons that do
> > > not support parsing a config file is this.
> > Iodine does not use any config AFAIK. So, should I treat systemd units as
> > config files and provide your units do not wait it may be started without
> > modifications by users??
> 
> Sorry not following you here. 
> 
> Ship the units. drop the /etc/sysconfig/foo files and point users to use
> http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F
> instead.
Ok.
Thanks for files, I'll integrate them in near days.
Comment 8 Jóhann B. Guðmundsson 2012-02-19 15:27:43 EST
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > (In reply to comment #3)
> No. It is just list of sustems on which it may be configured and built
> (configure script support it). Nothing more!
> 
> According to Ubuntu WIKI f.e. (
> https://wiki.ubuntu.com/systemd#Warning.21_Experimental_code ) it is
> experimental code (on Jan 2012) and does not supported.

First of all people in those distributions are the ones that add those configuration or ask for it's inclusions by submitting patches. 

Distribution specific code in systemd is generally frown upon and will be removed in the future.

Secondly Opensuse already has switched to systemd mageia will make the switch in their next release, gentoo and arch have supported it as an alternative for quite sometime now, Debian last time I check was debating if they should support three init systems I say have at it. 

Ubuntu develops and uses upstart and frankly nobody gives a flying .... what they do. They have already started to fork themselves in the corner.

And several embedded distro already are using systemd.
Comment 9 Pavel Alexeev 2012-02-23 09:30:34 EST
Please check that scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3812716
Comment 10 Gwyn Ciesla 2012-04-19 15:19:35 EDT
Pavel, do you intend to commit this, or should I go ahead?  I can modify the unit file to source /etc/sysconfig/foo.
Comment 11 Pavel Alexeev 2012-04-22 09:18:23 EDT
(In reply to comment #10)
> Pavel, do you intend to commit this
Off course. I had wait answer from someone (Jóhann B. Guðmundsson preferably) who test it.

It commited and built now http://koji.fedoraproject.org/koji/taskinfo?taskID=4013169

>, or should I go ahead?  I can modify the unit file to source /etc/sysconfig/foo.
I think it have no worth.
Comment 12 Fedora Update System 2012-04-22 09:28:11 EDT
iodine-0.6.0-0.rc1.9.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/iodine-0.6.0-0.rc1.9.fc16
Comment 13 Fedora Update System 2012-04-22 11:01:28 EDT
iodine-0.6.0-0.rc1.9.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/iodine-0.6.0-0.rc1.9.fc17
Comment 14 Gwyn Ciesla 2012-04-22 15:33:46 EDT
Got it.  Thanks!
Comment 15 Fedora Update System 2012-04-22 21:23:54 EDT
Package iodine-0.6.0-0.rc1.9.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing iodine-0.6.0-0.rc1.9.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-6433/iodine-0.6.0-0.rc1.9.fc17
then log in and leave karma (feedback).
Comment 16 Fedora Update System 2012-05-02 00:43:53 EDT
iodine-0.6.0-0.rc1.9.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 17 Fedora Update System 2012-05-03 03:19:07 EDT
iodine-0.6.0-0.rc1.9.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

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