The 28/08/12, Tom Gundersen wrote:
> I guess what I wrote was a bit misleading. Ignore socket/dbus
> activation (that is a side effect only). The point is that I don't see
> how to make daemons of Type=simple (the default), Type=dbus or
> Type=notify work without reimplementing much of systemd (regardless of
> when/how they are started).
> The point is that those kinds of daemons have moved functionality out
> of the daemon itself and into systemd, so the analogous must be done
> in the rc scripts.
Well, sd_notify looks pretty simplistic and I guess than writting a
helper program to handle this function would not be hard, if ever
Now, the simple type of systemd pretends to do optimization:
"if the process offers functionality to other processes on the system
its communication channels should be installed before the daemon is
started up [...] as systemd will immediately proceed starting
While it's a good feature to get pallelism, it's not expected by
historical sysVinit. So, it should be fine to start the required deamon
and let it configure environment or whatever it has to. Once it is fully
started or responding, continue the boot process. Yes, this "fully
started or responding" is the tricky part but with a fully serialized
starting process, it might be doable.
Though, I wouldn't expect such converter to create shell scripts roughly
equivalent to what systemd does. I think the main pitfall to such a tool
would be to try to get equivalent features with shell scripts.
Think another way: sysVinit serialize daemons startup. As a consequence,
for a minimal working convertion you only need to get the correct order
of the series. Advanced features of systemd should highly be ignored
from the process.
On top of that and for tricky parts of the conversion, it should not be
very hard to have conversion tunning from a complementary static source.
I mean, trying to convert everything /from unit files only/ in a smart
enough way could be very hard. Instead, it would be easier to do the
consersion from both unit files AND whatever other source or
configuration files (of the convertion tool).
IMHO, the best approach of this converter would be to turn it into a
micro-framework with _very simple features_ like templating support for
- simple unit files would not require a template; let the process go
- more complex unit files would only require to write a little template
with whatever static-and-dedicated code needed for a given
section/function of the built target (the sysVinit script).
The systemd-to-sysvinit-converter seems very hackable as a all-in-one
python script with only 658 lines. ,-)
> Hopefully the Debian guys have found a clever solution for this, I'd
> be interested to see it
I guess you meant "if the Debian guys have found".