Hello,
Carles Pina i Estany, le ven. 02 janv. 2026 08:00:10 +0100, a ecrit:
> > > I plan to document the steps in, at least:
> >
> > We'd rather integrate it into the package, so people don't have anything
> > to do but install the speech-dispatcher-festival package.
>
> I've tried to write the systemd units for socket activation for the Wiki
> documentation and that would be re-usable to add them in the
> speech-dispatcher-festival and I found some "blockers" (blockers for me,
> might be possible though and happy to try again).
>
> I haven't written socket activation services before but I found out:
> I think that the application (festival in that case) should be able to
> reuse an already opened socket? (systemctl binds 1314 and passes the
> file descriptor to it?).
Ah, right, festival would need to be taught how to get that fd, like
speech-dispatcher was taught.
> Then I thought that systemd could bind 1314 port, proxy to a second port
> (1315). And systemd could spawn "festival --server" indicating 1315.
That would be a headache, better just teach festival to use
SD_LISTEN_FDS_START:
if (sd_listen_fds(0) >= 1) {
/* Daemon launched via Systemd socket activation */
server_socket = SD_LISTEN_FDS_START;
}
> This almost worked and I could make it work... but I thought that would
> not be usable for speech-dispatcher-festival package because we want
> each "festival --server" running using the active user, so in a
> multi-user system that would cause problems. Is it correct that we want
> each user to have their own "festival --server" or one as
> "festival-server" user would be enough for the system?
Mmm, it's true that with multi-user questions rise. But if a user
starts festival --server without socket activation the problem is
already there, so I wouldn't bother trying to fix it. Actually, with
some containerization magic that could exist some day, user sessions
could have their own 1314 port so users don't step on each other. Anyway
that's for somebody to solve.
> For the Wiki documentation: since a user choose to enable the festival
> --server because the user is happy with it: I thought that keeping it
> simple is better than using socket activation. But I could change it.
Again, the end goal is to just integrate it in the festival package, so
that users won't *even* have to set up a systemd unit, but just install
speech-dispatcher-festival and voila.
Samuel
