Hello Rui Nano
Thought I'd just bump this upstream...
With best regards, Simon
On 03/30/2013 11:50 AM, Simon Lewis wrote:
> Hello Fernando
>
> Since fc17 upwards uses systemd and not sysvinit, should rtirq be made a
> systemd service?
It should... and it is great that you wrote a systemd unit! Thanks! But rtirq is now in Fedora, maybe you could file a bug in bugzilla and include the changed spec file there?
-- Fernando
> Something like:
>
> ____________________
>
> Name: systemd-rtirq
> Version: 20121105
>
> Source0: http://www.rncbc.org/jack/rtirq-20121105.tar.gz
>
> Requires: /bin/sh
> Requires: /usr/bin/chrt
>
> Conflicts: rtirq
>
> %prep
> %setup -q -n rtirq-20121105
>
> %build
> # nothing to do here
>
> %install
> cat> rtirq.service<< EOF
> [Unit]
> Description=Realtime IRQ thread system tuning
>
> [Service]
> Type=oneshot
> ExecStart=/etc/rc.d/init.d/rtirq start
> ExecStop=/etc/rc.d/init.d/rtirq stop
> RemainAfterExit=true
>
> [Install]
> WantedBy=multi-user.target
> EOF
>
> install -vDm644 rtirq.conf %{buildroot}%{_sysconfdir}/sysconfig/rtirq
> install -vDm755 rtirq.sh %{buildroot}%{_sysconfdir}/rc.d/init.d/rtirq
> install -vDm644 rtirq.service %{buildroot}%{_prefix}/lib/systemd/system/rtirq.service
>
> %post
> systemctl enable rtirq.service
>
> %preun
> systemctl disable rtirq.service
>
> %files
> %defattr(-,root,root,-)
> %config(noreplace) %{_sysconfdir}/sysconfig/rtirq
> %config(noreplace) %{_sysconfdir}/rc.d/init.d/rtirq
> %{_prefix}/lib/systemd/system/rtirq.service
> ______________________________
>
> With best regards, Simon Lewis
re. rtirq as systemd unit?
thanks Simon
i would suggest to have an additional and separate
rtirq.service
file instead of embedding its creation in the rpm spec; at least on openSUSE, you still have option to boot with sysvinit so that systemd is not engraved in stone, yet.dunno about fedora but the now older LSB (sysvinit) directives are still picked up and automatically integrated through corresponding systemd units or whatever, probably an openSUSE compatibility feature which might be absent in Fedora, can't really tell...
cheers
ps. nano who? :)
rtirq as systemd unit?
Hello Rui Nano
Yes, fc17 and fc18 support sysvinit directives through systemd. However, current fedora policy is that all packages built or rebuilt for new releases are to be rewritten using systemd services. Arch do this too...
Yes, I only embedded the creation of rtirq.service file in the rpm spec as it is not (yet) part of the rtirq source package.
With best regards, Simon
rtirq update - 2013 edition
that makes a new rtirq release, with both old sysvinit and the new systemd support.
new packages available:
rtirq-20130402-31.src.rpm
rtirq-20130402-31.noarch.rpm
cheers
rtirq.service
Hi,
I'm using this service file ("systemctl enable rtirq.service") but i'm encountering some problems. Apparently, the rtirq script is sometimes launched by systemd before the actual irq threads are created, resulting in rt priorities not set as expected. Rerunning the script once logged in correctly sets the priorities alright. I'm not familiar enough with systemd and linux in general to correct this behavior which shouldn't be too difficult.
Kind regards,
Xavier
re. rtirq.service
i'm not familiar either, not even a close relative. well, i'm still stuck in the old LSB era...
systemd must have some init sequence order of some sort, like "this service must run (or wait) after that other one" or something?
byee
Yeah it has, with the After
Yeah it has, with the After and Requires fields. The problem is that i don't know after what systemd service the rtirq script should be run.
re. Yeah it has, with the After
problem is that i don't know after what systemd service the rtirq script should be run
after or right before (wait/requires) one of the last that gets settled on a former sysinitv level 3, maybe? or at least requires the userspace file-systems be fully mounted already, i guess :)
a shot in the dark but what about adding this line to
rtirq.service
unit section:After=multi-user.target sound.target
hth.
[UPDATE:] new rtirq release, packages available:
rtirq-20130909-32.src.rpm
rtirq-20130909-32.noarch.rpm
cheers
Specifying After=multi-user
Specifying After=multi-user.target while there is a WantedBy=multi-user.target field seems contradictory to me. I guess that the script should be run after that udev has successfully loaded its modules.
re. Specifying After=multi-user
question is: is it fail or win? at least on my rigs (opensuse12.3) it seems to work out fine, rtirq gets started more or less in the mean time X gets the pitch ;)
cheers
Yep, it seems to work alright
Yep, it seems to work alright here too. Thanks a lot!
Add new comment