Bug 716994 - Provide native systemd unit file
Summary: Provide native systemd unit file
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kexec-tools
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: WANG Chao
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks: SysVtoSystemd
TreeView+ depends on / blocked
 
Reported: 2011-06-27 17:09 UTC by Jóhann B. Guðmundsson
Modified: 2013-06-07 08:33 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-06-07 08:33:37 UTC


Attachments (Terms of Use)

Description Jóhann B. Guðmundsson 2011-06-27 17:09:13 UTC
Description of problem:

https://fedoraproject.org/wiki/Features/SysVtoSystemd


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-06-28 17:58:16 UTC
is it possible to split kexec and kdump?

Comment 2 Jóhann B. Guðmundsson 2011-07-04 20:50:45 UTC
Note that you need to package the old sysv init script separately or drop it as stated but the packaging guidelines.

"SysV Initscripts
Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy, but Fedora still contains init mechanisms such as upstart which do not support the systemd unit file format. If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins. The guidelines for SysV initscripts can be found here: Packaging:SysVInitScript"

https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
http://fedoraproject.org/wiki/Packaging:Tmpfiles.d

Currently there's about 60/40 drop/keep ratio...

Comment 3 Jóhann B. Guðmundsson 2011-07-04 21:23:57 UTC
Hence hacks like these dont cut it...

[Unit]
Description=Crash recovery kernel arming
After=network.target 

[Service]
Type=oneshot
ExecStart=/etc/init.d/kdump start <--- wtf ;) 
RemainAfterExit=yes

Comment 4 Jóhann B. Guðmundsson 2011-07-06 22:13:54 UTC
I've flagged Kexec as done on https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd and you can close this as FIXED to get it off the alpha blocker bug 

Thanks for quick responces.

Comment 5 Fedora Admin XMLRPC Client 2011-07-15 15:01:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Jóhann B. Guðmundsson 2011-07-15 15:04:58 UTC
Could you please close this bug now that you have shipped a native systemd unit file so it goes of the bug trackers radar 

Any addtional changes can be submitted via update..

Thanks.

Comment 7 Fedora Update System 2011-09-09 19:12:05 UTC
kexec-tools-2.0.2-29.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kexec-tools-2.0.2-29.fc16

Comment 8 Fedora Update System 2011-09-10 18:57:40 UTC
Package kexec-tools-2.0.2-29.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kexec-tools-2.0.2-29.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/kexec-tools-2.0.2-29.fc16
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2011-09-30 18:55:32 UTC
kexec-tools-2.0.2-29.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Frank Ch. Eigler 2011-12-19 19:00:53 UTC
How is automatic kdump-start-at-boot supposed to work with these unit files?

# systemctl enable kdump.service
Warning: unit files do not carry install information. No operation executed.

Comment 11 Jóhann B. Guðmundsson 2011-12-19 20:41:54 UTC
If that happens the unit is missing an install section as in...

[Install]
WantedBy=multi-user.target

Just note that in some cases this can be intentionally left out just add the above is that is not the case.

Comment 12 Jóhann B. Guðmundsson 2011-12-19 20:42:42 UTC
s/is that/if that/

Comment 13 Fedora Admin XMLRPC Client 2012-04-16 06:12:22 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 14 Dave Young 2012-06-04 06:32:41 UTC
(In reply to comment #11)
> If that happens the unit is missing an install section as in...
> 
> [Install]
> WantedBy=multi-user.target
> 
> Just note that in some cases this can be intentionally left out just add the
> above is that is not the case.

Hello Johann

With this WantedBy line kdump service still fails start-at-boot, because it depends on /boot/ mounted, I tried add local-fs.target to Wants seems it does not help. Do you have idea about this?

Comment 15 Jóhann B. Guðmundsson 2012-06-04 13:42:47 UTC
The WantedBy line in the [Install] section of the unit is only relevant to which boot target you want the service to be enable in. 

You order startup ordering of units with After= or Before=. 

So the After= line should go from this "After=network.target" 

to this.., 

"After=local-fs.target network.target" 

To be order after local mount points 

and this... 

After=local-fs.target remote-fs.target network.target" 

if for some reason /boot is an remote filesystem. 

Try changing that and see if that fixes your problem

Now you might also want to add condition checks in the [Unit] section of the the unit as in.. 

ConditionPathExists=/boot 

If the above condition is not met as in /boot does not exist the unit will fail 

ConditionKernelCommandLine=crashkernel 


If crashkernel is not set on the kernel command line the unit will fail

Probably with this option you could request exception from fesco to enable the service by default. 

Putting this altogether you can test this unit file... 

[Unit]
Description=Crash recovery kernel arming
ConditionPathExists=/boot
ConditionKernelCommandLine=crashkernel
After=local-fs.target remote-fs.target network.target

[Service]
Type=oneshot
ExecStart=/usr/bin/kdumpctl start
ExecStop=/usr/bin/kdumpctl stop
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Comment 16 Dave Young 2012-06-07 06:53:26 UTC
Johann, Thanks

It still fails with your service content,I found my tested version is Fedora 17 beta, I tried F17 GA today the original kdump.service works just ok except a ldconfig problem of dracut:

ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
E: ldconfig exited ungracefully

Comment 17 Jóhann B. Guðmundsson 2012-06-07 08:14:11 UTC
(In reply to comment #16)
> Johann, Thanks
> 
> It still fails with your service content,I found my tested version is Fedora
> 17 beta, I tried F17 GA today the original kdump.service works just ok
> except a ldconfig problem of dracut:
> 
> ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission
> denied
> E: ldconfig exited ungracefully

The unit I mentioned there in comment 15 will fail if. 

A) /boot does not exist
B) crashkernel kernel parameter does not exist on the kernel command line.

These "local-fs.target remote-fs.target" should not be necessary I just added that to ensure you did not hit any kind of ordering problem 


[Unit]
Description=Crash recovery kernel arming
ConditionKernelCommandLine=crashkernel
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/bin/kdumpctl start
ExecStop=/usr/bin/kdumpctl stop
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

I suggest you test your unit on F16 so you aren't hitting some fallout from /usr move then you know remove "ro" from the kernel command line put "enforce=0" to rule out selinux etc. stuff like that to debug those permission errors.

Comment 18 Fedora Admin XMLRPC Client 2013-02-25 08:06:08 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 19 Fedora Admin XMLRPC Client 2013-02-25 08:09:04 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 20 Fedora End Of Life 2013-04-03 19:14:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19


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