Hi Samuel, list,
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.
I did it in:
https://salsa.debian.org/carlespina/festival/-/merge_requests/1
It's in draft. I want to test a bit more, but it seems to be working.
Feedback welcomed. Some notes below...
> > 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 is what I did.
> > 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
I implemented the socket activation. But I am still not sure of the user
details and if it's getting into a place that should not be...
What I did is socket activtation, and Festival runs as festival user
using DynamicUser=yes (my understanding is that it's a new user every
time).
> 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.
What would you change or double check on the Draft MR?
>
> > 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.
I think that the MR would do that.
On the other hand: would it confuse or cause any problem (e.g. security
problem) in a multi-user machine to have a festival server running under
a common users for all the users in the machine? Do you foresee
something or is good enough?
Thank you!
--
Carles Pina i Estany
https://carles.pina.cat | carles@pina.cat | cpina@debian.org
Attachment:
signature.asc
Description: PGP signature