Bug 770306

Summary: Provide native systemd service
Product: [Fedora] Fedora Reporter: Jóhann B. Guðmundsson <johannbg>
Component: havegedAssignee: Jiri Hladky <hladky.jiri>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: gwync, hladky.jiri, johannbg
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-02-14 23:00:12 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    
Attachments:
Description Flags
Native systemd unit for havege
none
SPEC File for systemd
none
Systemd service file
none
Systemd service file none

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