Re: s6 in production on Ubuntu - yeah!
On Wed, 4 Nov 2020 12:01:11 +0100 Oliver Schad wrote: > Hi everybody, > > we're proud to announce, that we have s6 in production in context of > platform as a service for our customers. LOL, NOW I understand why you kept asking how s6 does all these systemd actions. :-) SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: s6 in production on Ubuntu - yeah!
On Wed, 4 Nov 2020 12:01:11 +0100 Oliver Schad wrote: > Hi everybody, > > we're proud to announce, that we have s6 in production in context of > platform as a service for our customers. * * \ o / \|/ | C O O L / \ _ / \/ / - Thank you Oliver! Will the s6 package be available for just plain Ubuntu 16 and Ubuntu 20? If so, when? As soon as it's available on metal installable Ubuntu, I'll try it out. If it works well, I'll use it for my qemu and gnome-boxes VMs. Also, an upcoming business requirement might require me to boot to a thumb drive. If Ubuntu with s6 works well, I'll use that on my bootable thumb drive. Thanks so much! And thanks also to Laurent! This just might be wonderful. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: s6 in production on Ubuntu - yeah!
we're proud to announce, that we have s6 in production in context of platform as a service for our customers. That's awesome! Glad it's working, and thanks for your return! Thanks Laurent for supporting us to develop the integration of s6 in ubuntu 16 and 20. We can definitly recommend to engage Laurent for integration questions. The pleasure was mine :) -- Laurent
Re: s6 in production on Ubuntu - yeah!
Yep. Have been using s6-overlay inside docker containers. On top of the ubuntu 20.04 base image. It works well enough... Perhaps you could speak to some Canonical people about your usage of s6? Maybe it would be helpful to them, in some broader sense? Like to be a little bit less reliant upon systemd? On Wed, Nov 4, 2020 at 11:01 AM Oliver Schad wrote: > > Hi everybody, > > we're proud to announce, that we have s6 in production in context of > platform as a service for our customers. > > We started with the rollout on our container hypervisors and will > extend that to all of our LXC containers. > > We use Ubuntu 16 for now and will migrate that to Ubuntu 20. The reasons > we use that distro is, are some: > > - good package support from community > - canonical maintains LXC/LXD > - co-maintainers of ZFS > > So these are important reasons for us to stay on Ubuntu. > > Thanks Laurent for supporting us to develop the integration of s6 in > ubuntu 16 and 20. We can definitly recommend to engage Laurent for > integration questions. > > The reasons to migrate away from systemd are well known but to recap > that in short: > > - buggy > - bad support from development team (go-away mentality) > - over complex in every dimension > - really limited cause of DSL/config approach and really big config > language at the same time - more than 200 config statements - have > fun to know them all > - tries to enforce itself everywhere as dependency > - linux only > - tightly bundled to kernel interfaces, which might be dangerous in > container business (container's systemd might depend on specific > kernel interfaces of the host) > - cgroup massacre (mi-mi-mi that is my cgroup and nobody else is > allowed to use it) > > And I guess some more. The pain we had with systemd, journald and so on > was too much. > > Best Regards > Oli > > -- > Automatic-Server AG • > Oliver Schad > Geschäftsführer > Turnerstrasse 2 > 9000 St. Gallen | Schweiz > > www.automatic-server.com | oliver.sc...@automatic-server.com > Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47
s6 in production on Ubuntu - yeah!
Hi everybody, we're proud to announce, that we have s6 in production in context of platform as a service for our customers. We started with the rollout on our container hypervisors and will extend that to all of our LXC containers. We use Ubuntu 16 for now and will migrate that to Ubuntu 20. The reasons we use that distro is, are some: - good package support from community - canonical maintains LXC/LXD - co-maintainers of ZFS So these are important reasons for us to stay on Ubuntu. Thanks Laurent for supporting us to develop the integration of s6 in ubuntu 16 and 20. We can definitly recommend to engage Laurent for integration questions. The reasons to migrate away from systemd are well known but to recap that in short: - buggy - bad support from development team (go-away mentality) - over complex in every dimension - really limited cause of DSL/config approach and really big config language at the same time - more than 200 config statements - have fun to know them all - tries to enforce itself everywhere as dependency - linux only - tightly bundled to kernel interfaces, which might be dangerous in container business (container's systemd might depend on specific kernel interfaces of the host) - cgroup massacre (mi-mi-mi that is my cgroup and nobody else is allowed to use it) And I guess some more. The pain we had with systemd, journald and so on was too much. Best Regards Oli -- Automatic-Server AG • Oliver Schad Geschäftsführer Turnerstrasse 2 9000 St. Gallen | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpVcpbVnCrz7.pgp Description: OpenPGP digital signature
Re: s6 options
Hi Chaitanya s6 is not build to mirror all kernel interfaces for process management. This stuff is heavily system dependent and it makes to real sense to just copy a kernel interface to a s6 option, which just works on Linux. So the right way is to put that into the run script of your service - it's just an echo to the /proc hierarchy, in concrete /proc/self/oom_score_adj. It's that easy. Look at the Linux kernel documentation, how to handle that in detail (https://www.kernel.org/doc/Documentation/filesystems/proc.txt): === snip - CHAPTER 3: PER-PROCESS PARAMETERS -- 3.1 /proc//oom_adj & /proc//oom_score_adj- Adjust the oom-killer score These file can be used to adjust the badness heuristic used to select which process gets killed in out of memory conditions. The badness heuristic assigns a value to each candidate task ranging from 0 (never kill) to 1000 (always kill) to determine which process is targeted. The units are roughly a proportion along that range of allowed memory the process may allocate from based on an estimation of its current memory and swap use. For example, if a task is using all allowed memory, its badness score will be 1000. If it is using half of its allowed memory, its score will be 500. There is an additional factor included in the badness score: the current memory and swap usage is discounted by 3% for root processes. The amount of "allowed" memory depends on the context in which the oom killer was called. If it is due to the memory assigned to the allocating task's cpuset being exhausted, the allowed memory represents the set of mems assigned to that cpuset. If it is due to a mempolicy's node(s) being exhausted, the allowed memory represents the set of mempolicy nodes. If it is due to a memory limit (or swap limit) being reached, the allowed memory is that configured limit. Finally, if it is due to the entire system being out of memory, the allowed memory represents all allocatable resources. The value of /proc//oom_score_adj is added to the badness score before it is used to determine which task to kill. Acceptable values range from -1000 (OOM_SCORE_ADJ_MIN) to +1000 (OOM_SCORE_ADJ_MAX). This allows userspace to polarize the preference for oom killing either by always preferring a certain task or completely disabling it. The lowest possible value, -1000, is equivalent to disabling oom killing entirely for that task since it will always report a badness score of 0. == snap On Wed, 4 Nov 2020 15:45:19 +0530 billa chaitanya wrote: > Hi Team, > Is there any option available in s6 (like oom-kill-protect ) > equivalent to "OOMScoreAdjust" of systemd ? > > > Thanks, > Chaitanya -- Automatic-Server AG • Oliver Schad Geschäftsführer Turnerstrasse 2 9000 St. Gallen | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgphzxewWqK2T.pgp Description: OpenPGP digital signature
Re: S6-log
On 04.11.20 10:42, billa chaitanya wrote: Hi team, 1) does the log service of a corresponding long run service goes down when the long run service is made down using some s6 commands? (like s6-rc -d change It does not go down, because the dependency is the other way around. The service requires its log service, but the log service doesn't require its service to start (it's just useless without it). s6-rc -u change foo starts a service and all its dependencies (including its log service). s6-rc -d change bar stops all services depending on a service and the service. Stopping the log service stops the service as well. Starting the service starts the log service. 2) Shall we use s6-log for one shot services too? Oneshot services are started by the s6 oneshot runner. This long running service is required to start oneshots in a clean environment. 3) is there any command-line option we can provide to s6-log for stopping the running s6-log? What problem are you trying to solve? s6-log shouldn't have deal with replacing an other s6-log process itself.
S6-log
Hi team, 1) does the log service of a corresponding long run service goes down when the long run service is made down using some s6 commands? (like s6-rc -d change 2) Shall we use s6-log for one shot services too? 3) is there any command-line option we can provide to s6-log for stopping the running s6-log? Thanks Chaitanya
