Hey!
As you're aware, as of F15 we changed our default init system from sysvinit to systemd. But we have lots and lots of packages with daemons, and not all have thus far been migrated. Some maintainers haven't responded, some are too busy, some aren't sure how to go about it. In many cases, unit files have been posted by helpful individuals (Thanks Jóhann B. Guðmundsson!) but they're not yet in the packages.
If you're a Provenpackager, check out these two tracking bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=713562 https://bugzilla.redhat.com/show_bug.cgi?id=751869 (mostly this one)
And have a look at:
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
Look through, find something that looks manageable, and volunteer. Most maintainers will be receptive, I think, but remember, offer/ask before jumping in. If they're not responsive, we'll cross that bridge separately.
Thanks in advance!
-J
On 02/27/2012 08:42 PM, Jon Ciesla wrote:
Hey!
As you're aware, as of F15 we changed our default init system from sysvinit to systemd. But we have lots and lots of packages with daemons, and not all have thus far been migrated. Some maintainers haven't responded, some are too busy, some aren't sure how to go about it. In many cases, unit files have been posted by helpful individuals (Thanks Jóhann B. Guðmundsson!) but they're not yet in the packages.
If you're a Provenpackager, check out these two tracking bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=713562 https://bugzilla.redhat.com/show_bug.cgi?id=751869 (mostly this one)
And have a look at:
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
Look through, find something that looks manageable, and volunteer. Most maintainers will be receptive, I think, but remember, offer/ask before jumping in. If they're not responsive, we'll cross that bridge separately.
It would be better to walk through this list [1] which was designed specifically with PP participation in mind as discussed with Toshio during the F16 development cycle.
Just add your name to Proven Packager and flag it passed when you have packaged the relevant component.
JBG
1. https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F17
On 2012-02-27, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
It would be better to walk through this list [1] which was designed specifically with PP participation in mind as discussed with Toshio during the F16 development cycle.
Just add your name to Proven Packager and flag it passed when you have packaged the relevant component.
The page is F17 feature. Should I flag the component as passed when fixed in rahwide, or only after fixing in F17?
-- Petr
On Tue, Feb 28, 2012 at 3:53 AM, Petr Pisar ppisar@redhat.com wrote:
On 2012-02-27, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
It would be better to walk through this list [1] which was designed specifically with PP participation in mind as discussed with Toshio during the F16 development cycle.
Just add your name to Proven Packager and flag it passed when you have packaged the relevant component.
The page is F17 feature. Should I flag the component as passed when fixed in rahwide, or only after fixing in F17?
Well, ideally F17, if you can get it in by Beta. If you get it only as far as rawhide, post-Beta, then mark it complete.
-J
-- Petr
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 2012-02-27 at 14:42 -0600, Jon Ciesla wrote:
Hey!
As you're aware, as of F15 we changed our default init system from sysvinit to systemd. But we have lots and lots of packages with daemons, and not all have thus far been migrated.
Hi, 3 things 1- I like have help on convert: vboxweb-service from VirtualBox on rpmfusion. "http://cvs.rpmfusion.org/viewvc/*checkout*/rpms/VirtualBox-OSE/F-17/vboxweb-..." off-list
2- how I do ? with systemd : service iptables status service iptables save
3 - we got this message on /var/log/message systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start.
I thing we want read /var/run/sendmail.pid , are we missing /var ?
Thanks in advance,
On 02/28/2012 02:09 AM, Sérgio Basto wrote:
Hi, 3 things 1- I like have help on convert: vboxweb-service from VirtualBox on rpmfusion. "http://cvs.rpmfusion.org/viewvc/*checkout*/rpms/VirtualBox-OSE/F-17/vboxweb-..." off-list
First of all this is for the rpmfusion list and was off topic for this thread that said...
Here is a vboxweb.service that should work for if not you can read the systemd man pages and figure out the rest.
### vboxweb.service ###
[Unit] Description=VirtualBox OSE Web Service After=network.target
[Service] Type=forking PIDFile=/run/vboxweb.pid ExecStart=/usr/bin/vboxwebsrv --pidfile /run/vboxweb.pid --background
[Install] WantedBy=multi-user.target
"/etc/sysconfig/$SERVICE" was dropped since...
a) it does not exist in the package spec file
b) upstream wont accept submitted units with /etc/sysconfig/ files which means those that still want to do this will need start carrying patches in the form of EnvironmentFile=-/etc/sysconfig/$SERVICE against upstream units to add this behaviour to units.
Doing so would go against our upstream mantra I believe....
c) This is no longer necessary since users really should be following [1]
2- how I do ? with systemd : service iptables status
systemctl status iptables.service
iptables -L or for the exact initscript command that was used, run /usr/libexec/iptables.init status
service iptables save
iptables-save
or for the exact initscript command that was used, run /usr/libexec/iptables.init save
3 - we got this message on /var/log/message systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start.
What's happening here is that sendmail is daemonizes itself in a racy way.
It exits the original process before the child writes the PID file which means that when systemd attempts to read the service's PID file, it is not there yet.
The proper steps to daemonize a process are described and can be found in [2]
I thing we want read /var/run/sendmail.pid , are we missing /var ?
No we are not however since [3] all path should really be pointing to /run at this point instead of that symlink...
JBG
1. http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_... 2. http://0pointer.de/public/systemd-man/daemon.html 3. http://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html
On Tue, 2012-02-28 at 04:52 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/28/2012 02:09 AM, Sérgio Basto wrote:
Hi, 3 things 1- I like have help on convert: vboxweb-service from VirtualBox on rpmfusion. "http://cvs.rpmfusion.org/viewvc/*checkout*/rpms/VirtualBox-OSE/F-17/vboxweb-..." off-list
First of all this is for the rpmfusion list and was off topic for this thread that said...
Here is a vboxweb.service that should work for if not you can read the systemd man pages and figure out the rest.
### vboxweb.service ###
[Unit] Description=VirtualBox OSE Web Service After=network.target
[Service] Type=forking PIDFile=/run/vboxweb.pid ExecStart=/usr/bin/vboxwebsrv --pidfile /run/vboxweb.pid --background
[Install] WantedBy=multi-user.target
"/etc/sysconfig/$SERVICE" was dropped since...
a) it does not exist in the package spec file
b) upstream wont accept submitted units with /etc/sysconfig/ files which means those that still want to do this will need start carrying patches in the form of EnvironmentFile=-/etc/sysconfig/$SERVICE against upstream units to add this behaviour to units.
Doing so would go against our upstream mantra I believe....
c) This is no longer necessary since users really should be following [1]
2- how I do ? with systemd : service iptables status
systemctl status iptables.service
iptables -L or for the exact initscript command that was used, run /usr/libexec/iptables.init status
service iptables save
iptables-save
or for the exact initscript command that was used, run /usr/libexec/iptables.init save
3 - we got this message on /var/log/message systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start.
What's happening here is that sendmail is daemonizes itself in a racy way.
It exits the original process before the child writes the PID file which means that when systemd attempts to read the service's PID file, it is not there yet.
The proper steps to daemonize a process are described and can be found in [2]
I thing we want read /var/run/sendmail.pid , are we missing /var ?
No we are not however since [3] all path should really be pointing to /run at this point instead of that symlink...
JBG
http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_... 2. http://0pointer.de/public/systemd-man/daemon.html 3. http://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html
Thanks very much. I will checkout when I have time (could be not this week), I give you feedback for good or for bad.
Thanks,
On Tue, 2012-02-28 at 04:52 +0000, "Jóhann B. Guðmundsson" wrote:
b) upstream wont accept submitted units with /etc/sysconfig/ files which means those that still want to do this will need start carrying patches in the form of EnvironmentFile=-/etc/sysconfig/$SERVICE against upstream units to add this behaviour to units.
I hope that systemd always supports sysV, has part of specification of systemd. IMHO.
Thanks,
On 04/14/2012 12:26 PM, Sérgio Basto wrote:
I hope that systemd always supports sysV, has part of specification of systemd. IMHO.
It will for sometime due to 3rd parties but that does not give us an excuse to not migrate all our legacy sysv init scripts to native systemd units.
Hopefully we manage to migrate all that stuff in F18 no later than F19 so if you have submitted units against your components please package them.
Thanks
JBG
3 - we got this message on /var/log/message systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start.
Probably: http://bugzilla.redhat.com/show_bug.cgi?id=748171
IMHO this message should be harmless because there is inotify workaround in systemd.
I thing we want read /var/run/sendmail.pid , are we missing /var ?
/run is bind mounted to /var/run
regards
Jaroslav
devel@lists.stg.fedoraproject.org