#809 Move icecast to systemd in F17--16
Closed None Opened 12 years ago by ppisar.

= Phenomenon =
I request for approval to move icecast SystemV init script to native systemd unit in F17 and F16 as [https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript this is explicitly forbidden by packaging guidelines].

= Reason =
Current init script does not work with systemd emulation (tested in F16). Attempt to start blocks and after timing-out the job is marked as failed despite the icecast daemon starts. I did the transition in F18 as [https://bugzilla.redhat.com/show_bug.cgi?id=782149] and [https://bugzilla.redhat.com/show_bug.cgi?id=656601].

= Recommendation =
I think it's better to do the transition in stable Fedora release than to keep it broken.


Adding meeting keyword.

I pushed the change into F17 Alpha as allowed by [http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/160157 FESCo meeting 2012-02-27].

The F16 branch question is still opened.

We forgot this one yesterday.

I'm fine with replacing the sysvinit script by unit in F-16, because icecast doesn't work at all. I guess all sysvinit scripts, which don't work at all should be replaced even in stable releases.

It could be useful to have a complete list of sysvinit scripts not working in systemd environment for future post mortem analysis.

Is there no way to get the sysvinit script working in f16? Have you tried asking systemd maintainers?
It may have run into a legit bug that needs to be fixed or worked around.

I'd prefer you take that path before switching to native unit file. If of course systemd folks say it cannot work with the compat mode, then moving to native is better than total non working.

I guess the problem is the icecast program cannot create a PID file (for whatever reason, /var/run being tmpfs probably), so the daemon function in SystemV init script waits forever. I will try to investigate it more deeply.

Replying to [comment:4 kevin]:

Is there no way to get the sysvinit script working in f16? Have you tried asking systemd maintainers?
It may have run into a legit bug that needs to be fixed or worked around.

I'd prefer you take that path before switching to native unit file. If of course systemd folks say it cannot work with the compat mode, then moving to native is better than total non working.

I guess we forbid migration from sysvinit script to unit, because it could change behaviour in a stable release. But if it didn't work, it could only improve things.

F16 does not work because: /var/run as tmpfs wipes /var/run/icecast where daemon places PID file. Lennart in turn provided tmpfiles.d to create the directory. But tmpfiles.d is effective after reboot, so the directory is still missing between package installation and reboot. Then Lennart proposed %ghosting the directory to prevent rpm --verify complains. This forbids to creating the directory at install time. What another hack-fix will Lennart propose for this issue? It seems like a fix for fix coming from all these changes.

I think migrating to native unit is the best option here.

Actually the directory should not be %ghost but a regular directory in the package. Then it will be normally created on install of the package and creating it on boot will be handled by tmpfiles.d config. This is no hack and it is not related to whether the init file is an unit or sysvinit script.

Then what's purpose of ghosting /var/run files as requested by Lennart in [https://bugzilla.redhat.com/show_bug.cgi?id=656601 bug #656601] and [http://lists.fedoraproject.org/pipermail/devel-announce/2010-November/000726.html his e-mail]? The files are needed for a process, then then must be owned by the package, or their are not needed, thus they don't need to be either created nor owned in any special manner. Or can you give an use case?

The actual guidelines are in [https://fedoraproject.org/wiki/Packaging:Tmpfiles.d], and don't request %ghost-ing the directory (and yes, this is impossible to find from the Packaging:Systemd page - anyone care to file a FPC ticket?).

From time to time, we manage to do better than keeping the knowledge in mailing list archives :)

Thanks. Ignoring the recommendation to ghost files helped. You can close this request.

Login to comment on this ticket.

Metadata