Bug 661241 - Providing native systemd file for upcoming F15 Feature Systemd
Summary: Providing native systemd file for upcoming F15 Feature Systemd
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: wesnoth
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: SysVtoSystemd
TreeView+ depends on / blocked
 
Reported: 2010-12-08 09:43 UTC by Michał Piotrowski
Modified: 2012-02-01 02:05 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-01 02:05:56 UTC


Attachments (Terms of Use)
wesnothd.service (230 bytes, text/plain)
2010-12-08 09:46 UTC, Michał Piotrowski
no flags Details

Description Michał Piotrowski 2010-12-08 09:43:59 UTC
The attached file is a native systemd file for upcoming F15 Feature [1]

Please read [2] on how to packaging and installing systemd Service files.

To learn more about Systemd daemon see [3].

To view old SysV with the new Systemd site by site see for your component see [4]

If you have any question dont hesitate to ask them on this bug report.

1.http://fedoraproject.org/wiki/Features/systemd

2.https://fedoraproject.org/wiki/Systemd_Packaging_Draft

3.http://0pointer.de/public/systemd-man/daemon.html

4.https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability

Comment 1 Michał Piotrowski 2010-12-08 09:46:53 UTC
Created attachment 467428 [details]
wesnothd.service

There is a small problem after stopping service

systemctl status wesnothd.service
wesnothd.service - Wesnoth game server
	  Loaded: loaded (/lib/systemd/system/wesnothd.service)
	  Active: failed since Wed, 08 Dec 2010 10:42:47 +0100; 897ms ago
	 Process: 6535 (/usr/sbin/wesnothd --daemon $WESNOTHD_OPTIONS, code=exited, status=0/SUCCESS)
	Main PID: 6536 (code=exited, status=143)
	  CGroup: name=systemd:/system/wesnothd.service

Don't know why it's "Active: failed".

Comment 2 Michał Piotrowski 2010-12-09 08:43:58 UTC
This service should start after network.target
After=syslog.target network.target


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