From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from alyss.skarnet.org (alyss.skarnet.org [95.142.172.232]) by inbox.vuxu.org (Postfix) with SMTP id 616B9307FF for ; Fri, 6 Dec 2024 00:03:33 +0100 (CET) Received: (qmail 33327 invoked by uid 89); 5 Dec 2024 23:03:58 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 33320 invoked from network); 5 Dec 2024 23:03:58 -0000 From: "Laurent Bercot" To: supervision@list.skarnet.org Subject: Re[2]: Have an external script wait for a oneshot service Date: Thu, 05 Dec 2024 23:03:30 +0000 Message-Id: In-Reply-To: References: <20241204140015.4e635037306d88117e053994@freesa.org> <2571a89b-ac74-4d9e-b8c6-ff0fe05cebb7@sopka.ch> <20241204141821.ee2a00c996c948f2feb42dec@freesa.org> <4faed412-6fc0-4833-8f76-b6a74667c869@sopka.ch> <3d1391e4-b240-4675-a839-a34c39d474b3@sopka.ch> Reply-To: "Laurent Bercot" User-Agent: eM_Client/10.1.4588.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >- A Users might want to achieve a state of the user-tree on boot, whic= h is impossible without s6-rc > Though I have to admit that I can not find concrete examples of = application. Exactly. That's the YAGNI principle: don't try to solve problems you haven't encountered yet. Chances are you'll actually never encounter them. Adding complexity in the name of "just in case" is overengineering and it will only worsen your design. And if I have learned anything about users, it's that most of your users will have trouble understanding what a supervised service is, and if you start talking about them about s6-rc services, their brain will start melting and they'll run away from your system as fast as they can. And they won't be wrong. >- B Imagine the following scenario: > > A user wants to run a script every day at 12:00 and sets up a s= nooze user-longrun for that, So far so good (I understand Brett's point, but that should not be the basis for an argument, because there are other things that can only be achieved via a longrun, crontab is only an example here) > which he installs and starts using s6-rc-init and s6-rc respect= ively while logged in, ... and here you lose me. The user has a supervision tree. They can install their longrun=20 directly in it. They don't need s6-rc for that. Pure s6 is enough. Their service will run as long as they keep it there. They can stop it with s6-svc. Or s6-svunlink. s6-rc is good when you have an intricate mix of longruns and oneshots. This is the case in a boot sequence. This *might* be the case for a user login sequence. And this is almost certainly *not* the case for a set of user services that you would hypothetically start at boot time and do stuff with before a user even logs in, wtf. You want to run s6-rc at login time, sure, I can totally see where i can be beneficial there. But earlier? Even systemd doesn't run user stuff before a user logs in. And if *they* don't do it, it means that there are ZERO use cases. | Now the server reboots, brings up the user-tree again, but=20 without the snooze user-service of course. And what is preventing that? The fact that your default bundle does not include the services that the user has defined themself. This should=20 give you a hint that this design goes against what supervision is supposed to be doing, and thus, that it's not a good design. Whatever longrun the user wants to have survive a reboot should survive a reboot and the user shouldn't need a PhD to accomplish that. If the user has installed their service in the pure s6 way with e.g. one (1) call to s6-svlink, it works: after a reboot, the snooze will be back up. >All in all this would make things more complicated, >in that users have to learn and consider more things while distribution ma= intainers have more work. Exactly. You're *so close*. >So while I agree to you, that until I find a concrete examples for A, >s6-rc during "non-login" time is technically not necessary, >lacking it makes many things more inconvenient, complex and inconsistent. It's more inconvenient, complex and inconsistent because you want to keep the framework that makes it so. Remove a little more and you'll have something elegant again. >On the other side, why not have it? It is a feature that is probably going = be >useful at some point and comes with little to no cost. Little to no cost? This whole thread is about the costs! And from my perspective, "probably going to be useful at some point" is a pretty light argument, it's definitely not going to outweigh "too complex to make work properly". >Finally, I want to say that I really admire you being very conservative on = adding features, >it is great to know that s6/s6-rc will stay sleek and efficient. Thank you. Now take inspiration from that for your own designs. ;) -- Laurent