Bug 770306 - Provide native systemd service
Summary: Provide native systemd service
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: haveged
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jiri Hladky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 751869
TreeView+ depends on / blocked
 
Reported: 2011-12-25 22:11 UTC by Jóhann B. Guðmundsson
Modified: 2012-02-16 00:42 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-14 23:00:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Native systemd unit for havege (144 bytes, text/plain)
2011-12-25 22:11 UTC, Jóhann B. Guðmundsson
no flags Details
SPEC File for systemd (5.40 KB, text/x-rpm-spec)
2012-02-14 22:58 UTC, Jiri Hladky
no flags Details
Systemd service file (216 bytes, application/octet-stream)
2012-02-14 22:59 UTC, Jiri Hladky
no flags Details
Systemd service file (192 bytes, application/octet-stream)
2012-02-15 20:41 UTC, Jiri Hladky
no flags Details

Description Jóhann B. Guðmundsson 2011-12-25 22:11:14 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 2011-12-25 22:11:49 UTC
Created attachment 549515 [details]
Native systemd unit for havege

Comment 2 Gwyn Ciesla 2012-02-14 16:46:07 UTC
Jiri, any objection to my making this change?

Comment 3 Jiri Hladky 2012-02-14 19:15:30 UTC
Hi Jon and Jóhann,

I'm sorry for the delay. I was waiting for the new haveged release. Version 1.4 was released just now and I will move it to SystemD.

I have checked the attachment - there is one typo but other than that it looks fine.

Thanks
Jirka

Comment 4 Gwyn Ciesla 2012-02-14 19:18:07 UTC
Great, thank you!

Comment 5 Jiri Hladky 2012-02-14 22:58:36 UTC
Created attachment 562086 [details]
SPEC File for systemd

SPEC File for systemd

Comment 6 Jiri Hladky 2012-02-14 22:59:25 UTC
Created attachment 562088 [details]
Systemd service file

Systemd service file

Comment 7 Jiri Hladky 2012-02-14 23:00:12 UTC
Done:-)

Comment 8 Jóhann B. Guðmundsson 2012-02-15 10:28:00 UTC
You should drop the After=syslog.target it's no longer necessary and fix PIDFile= path to be /run not /var/run which points to the actual path and will not be change while the /var/run symlink might be removed in the not too distant future.

Comment 9 Jiri Hladky 2012-02-15 20:41:24 UTC
Created attachment 562327 [details]
Systemd service file

Thanks for the hints!

I have updated service file accordingly.

Comment 10 Jiri Hladky 2012-02-15 22:27:43 UTC
(In reply to comment #8)
> You should drop the After=syslog.target it's no longer necessary and fix
> PIDFile= path to be /run not /var/run which points to the actual path and will
> not be change while the /var/run symlink might be removed in the not too
> distant future.

Hi Johann,

I have updated service file but I have one question regarding PID file.

Software will by default create PID File at location /var/run/haveged.pid This cannot be changed right now (but I can ask upstream to add such command line option if needed) 

I have now updated service file to be
PIDFile=/run/haveged.pid

I have seen that there are now two PID Files created:

$ls -l /var/run/haveged.pid /run/haveged.pid
-rw-r--r-- 1 root root 4 Feb 15 23:16 /run/haveged.pid
-rw-r--r-- 1 root root 4 Feb 15 23:16 /var/run/haveged.pid

This is obviously wrong. Could you please clarify what's the right way to handle this? Should PIDFile= be omitted when software is creating PIDFile automatically? Or should PIDFile= match the PID file created by software?

Thanks a lot
Jirka

Comment 11 Jóhann B. Guðmundsson 2012-02-16 00:31:07 UTC
change the PIDFile= path back to /var/run then check with upstream what they have to say usually there is a configuration file or a compile option that sets the used pid path. 

Dont forget to submit that unit file upstream as well.

You can then just change the PIDFile path later via update or when we create a Feature page for it and various other cleanup stuff.

Comment 12 Jiri Hladky 2012-02-16 00:42:57 UTC
Hi Jóhann,

thanks for the clarification. I have inspected the source code, currently there is no way how to influence location of the PID File. I have requested it.

I have already sent service file to the upstream as well.

Thanks a lot
Jirka


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