[ubuntu-studio-devel] Shouldn't rtirq become a systemd unit?

[Len Ovens]

On Thu, 6 Aug 2015, Ralf Mardorf wrote:

> I'm a systemd user, but I don't like systemd and I much more dislike
> the generator-hybrid-systemd.

:)

> What does Requires= After= Before= do, if you use it in several service
> files? Everybody will lose track of the unit order.
>
> http://www.freedesktop.org/software/systemd/man/systemd.unit.html
>
> If you search by Ctrl+F you'll not find RemainAfterExit, oneshot.
>
> I don't know where upstream documented everything.
>
> That systemd already is hard to use is the reason why I dislike to mix
> it with init files.

On the other hand init files mean that any program that has init files 
that someone DL source for can be used.

I personally think there should be one systemd event/script that deals 
with all system configuration. It would work much like many such things 
where it would go through two or three directories running config scripts 
one by one. Similar to init.d BTW. One of those directories would be where 
packages put there config options, another would be for distro compilers 
to put overriding config options and yet another could be used by the user 
to override both. In the case of rtirq, the current /etc/default/rtirq 
would probably continue to work fine.

Take setting up performance instead of ondemand for example. I do not know 
if this has yet been cleaned up. It has been, even under upstart, an 
init.d script.... err, scripts. There were two of them stock to set 
ondemand... made by two people who did not talk to each other, I think. 
The first one starts ondemand, the second one waits 60 seconds after 
startup and then sets ondemand. I think the original idea was that the 
system would start in performance for faster startup and then switch to 
ondemand after the user had logged in. The idea didn't help as much as 
hoped and so the first script just got change to ondemand for the whole 
shot, but the second was never removed. So someone setting up their system 
to go performance from rc.local will wonder why it goes into performance 
and then suddenly it is back to ondemand. Changing the bad script will 
mess up upgrades, so the only way to fix it is to also put a delay in 
rc.local or do a "sh script &". Allowing Intel Boost to run may actually 
make startup faster than performance...

There are probably more such things that should be reported as bugs I 
guess.

Personally I have been waiting for the change to system.d to be called 
finished before I start messing with it.

--
Len Ovens
www.ovenwerks.net