hi,
On 03 Jan 2026 at 19:06:01, Samuel Thibault wrote:
> 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;
> }I will look into that and report here (likely not earlier than next week, likely later). If for some reason you, or anyone else here, implements it before me, let me know please (and happy to test it, write the systemctl unit, etc.) > > 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 First of all: if we are happy that the socket activation is the way to go I will look into that. Question: would be better (or possible?) to have "festival --server" running as a "festival" user, for all users? (with socket activation). I was avoiding that in case that a user would need to tweak some festival user settings. But I haven't used festival in this mode and I don't know if it's needed or not. > 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. If it ever happens it would be interesting. I think that the problem could already be solved if we created (via systemd) a UNIX domain socket (file socket). systemctl could create one UNIX domain socket logged user (as a systemctl user unit), then use systemctl activation in order to launch a festival for each user (specific socket) passing the file descriptor. Would that work and have any advantage? I haven't looked if this is feasible (but I suspect that is more work to make speech-dispatcher-festival use socket files, and also festival --server to also use a socket file. > > 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. yep (and I want to look into this). On the other hand, in very short term, I wanted to document how to use the current system (I am helping a user that will show it really soon to a group of interested people and might use it himself). -- Carles Pina i Estany https://carles.pina.cat | [email protected] | [email protected]
signature.asc
Description: PGP signature
