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 | [email protected] | [email protected]
signature.asc
Description: PGP signature
