Bug 770306 - Provide native systemd service
Provide native systemd service
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: haveged (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jiri Hladky
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 751869
  Show dependency treegraph
 
Reported: 2011-12-25 17:11 EST by Jóhann B. Guðmundsson
Modified: 2012-02-15 19:42 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-14 18:00:12 EST
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 unit for havege (144 bytes, text/plain)
2011-12-25 17:11 EST, Jóhann B. Guðmundsson
no flags Details
SPEC File for systemd (5.40 KB, text/x-rpm-spec)
2012-02-14 17:58 EST, Jiri Hladky
no flags Details
Systemd service file (216 bytes, application/octet-stream)
2012-02-14 17:59 EST, Jiri Hladky
no flags Details
Systemd service file (192 bytes, application/octet-stream)
2012-02-15 15:41 EST, Jiri Hladky
no flags Details

  None (edit)
Description Jóhann B. Guðmundsson 2011-12-25 17:11:14 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 2011-12-25 17:11:49 EST
Created attachment 549515 [details]
Native systemd unit for havege
Comment 2 Gwyn Ciesla 2012-02-14 11:46:07 EST
Jiri, any objection to my making this change?
Comment 3 Jiri Hladky 2012-02-14 14:15:30 EST
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 14:18:07 EST
Great, thank you!
Comment 5 Jiri Hladky 2012-02-14 17:58:36 EST
Created attachment 562086 [details]
SPEC File for systemd

SPEC File for systemd
Comment 6 Jiri Hladky 2012-02-14 17:59:25 EST
Created attachment 562088 [details]
Systemd service file

Systemd service file
Comment 7 Jiri Hladky 2012-02-14 18:00:12 EST
Done:-)
Comment 8 Jóhann B. Guðmundsson 2012-02-15 05:28:00 EST
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 15:41:24 EST
Created attachment 562327 [details]
Systemd service file

Thanks for the hints!

I have updated service file accordingly.
Comment 10 Jiri Hladky 2012-02-15 17:27:43 EST
(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-15 19:31:07 EST
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-15 19:42:57 EST
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.