Systemd unit parser and s6 generator
Hi everybody I don't know, if somebody has tried that ever. However we want to continue to use Ubuntu on s6 and packages today our s6 "units" manually. We've build a generator for that, that creates a base of service. But the call of this generator is once by a human being which manually decides which options make sense. Later he/she modifies maybe the generated result. We've discussed internally if we change that process and try to write a systemd unit parser, because all units are there in Ubuntu. If we could catch 90% of all cases, we need, we would be happy. If it would take 2 weeks of work, that would be fine. Did somebody of you try to implement something? What are your thoughts? Best Regards Oli -- Automatic-Server AG ••••• Oliver Schad Geschäftsführer Hardstr. 46 9434 Au | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpDMaY8GqTIY.pgp Description: OpenPGP digital signature
Re: "Back off" setting for crashing services with s6+openrc?
On Mon, 26 Sep 2022 23:00:48 + Colin Booth wrote: > On Thu, Sep 22, 2022 at 01:21:46PM -0700, John W Higgins wrote: > > run_my_crashing_app || sleep 10 > > > > Work? The run script will sit there for 10 seconds if your app > > fails. Not built in - but should accomplish the task pretty easily. > > > > John W Higgins > Put the backoff in the finish script. The API is to run finish with > the exit code and signal (if appropriate) as $1 and $2 respectively. > With that information you can have finish make decisions about if it > should delay restarting, set the service down in the face of a > permanent error, or so on. Note that by default finish has a five > second deadline so if you want to delay a restart for ten seconds > you'll need to increase that deadline with a timeout-finish file. Sounds in theory good, but in practice I would split the whole thing in 2 parts: - define start timings in "finish" - do start timings in "run" Why? I expect stopping more or less immediatly and the timeout of 5 seconds of "finish" meets my expectations. Of course it's not the right semantic of starting, that delaying is part of start. However, with the current features of s6 it's more logical to extend the starting phase, because it sleeps some time. But I'm still not happy with that. Uhm, don't know, if it would work: could we model that delay as a service dependency? So if the dependency is up, the service itself can be started. Inside of the finish script of the real service, you would write the stats, which controls the behaviour of the delay service. So we had a "delay service", and a real service and you wouldn't had to model some unvisible magic inside of run scripts. I.e. if you would call the service "delay-myapp" you would exactly see, why your service doesn't start, now. I was thinking about that issue, if you aren't familiar with a setup, what would you expect as an administrator? I wouldn't expect delay magic in run or finish scripts. I mean, imagine you have to debug why a service doesn't start. Reading the run or finish scripts for that is not that fancy. Best Regards Oli -- Automatic-Server AG • Oliver Schad Geschäftsführer Hardstr. 46 9434 Au | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpt_tVbLYxsB.pgp Description: OpenPGP digital signature
Re: "Back off" setting for crashing services with s6+openrc?
On Thu, 22 Sep 2022 13:21:46 -0700 John W Higgins wrote: > Good Day, > > On Thu, Sep 22, 2022 at 1:13 PM Tor Rune Skoglund > wrote: ... > > > As a generic question, is there any setting with this s6+openrc > > config that would make s6 "back off" a configurable number of > > seconds before doing the restart? > > > > > Does something as simple as changing your run script to be something > like > > run_my_crashing_app || sleep 10 > > Work? The run script will sit there for 10 seconds if your app fails. > Not built in - but should accomplish the task pretty easily. You could propably outsource the backoff mechanism, which can handle some statistics. Something like that: https://pastebin.com/aH3EDGLG You would use it in your run script as: exec with_backoff my_daemon Best Regards Oli -- Automatic-Server AG • Oliver Schad Geschäftsführer Hardstr. 46 9434 Au | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpqKkctcfwf7.pgp Description: OpenPGP digital signature
Re: Pattern for multiple subservices and dynamic discovery i.e. VPN
On Thu, 18 Aug 2022 06:04:25 -0400 Davor Ocelic wrote: > On Thu, Aug 18, 2022 at 11:32:30AM +0200, Oliver Schad wrote: > How about an approach that would be more tightly integrated > with s6? For example: > > > - we need an scanning component for the desired state of running > > instances (something like 'find /etc/openvpn -name "*conf"') > > Right, the scanning component would be the key part. Ideally it > would use inotify so that it doesn't have to poll and also it would > get the type of event automatically (file created or file deleted). > > After it sees that a change in a directory has occurred (let's say a > file was added), then it does the following: > > - It creates the appropriate service directory for this particular > VPN config (possibly based on a template) > - It calls s6-svlink or the like to register the new service, which > automatically also notifies s6-svscan that a new service has been > added That would just move 3 components to another level but they are still needed: scanning existing service directories, diffing between desired and current state and applying - so creating or removing directories. I see there a problem with multiple dynamic services. I'm not sure about concurrency behaviour of updating processes in the service directory. Maybe Laurent can explain problems in that area, if they exist. I'm not sure how complex the supervision itself is - however I would love to solve the problem without doing supervision on my own. I thought about your approach as well but it really depends how resilient an update process is. Best Regards Oli -- Automatic-Server AG • Oliver Schad Geschäftsführer Hardstr. 46 9434 Au | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpObylnQ62PO.pgp Description: OpenPGP digital signature
Re: Pattern for multiple subservices and dynamic discovery i.e. VPN
Dear Laurent, thanks a lot for your quick response. I understand, that dynamic discovery needs some thoughts to implement in an easy and flexible way. Just to understand the requirements, if we want to implement that today: - we need an scanning component for the desired state of running instances (something like 'find /etc/openvpn -name "*conf"') - we need an scanning component for the current state in process list - we need a diffing component - we need a state applier component A component could be a shell function. Applying state would mean to fork and exec. A process tree would look like /usr/bin/s6-svscan s6-supervise vpn-manager vpn-manager openvpn foo1.conf openvpn foo2.conf Best Regards Oli On Wed, 17 Aug 2022 11:04:50 + "Laurent Bercot" wrote: > > > >I'm looking for a pattern to solve a problem, where you have to > >discover dynamically the services you have to start. > > > >Examples could be VPN configurations, where you discover the > >configuration files and start for every file an instance of the VPN > >service. > > Hi Oliver, > > Dynamic instantiation is a real pain point - it's an often requested > feature, but it's surprisingly hard to make it work correctly and > safely in a supervision scheme. Supervision works very well in static > environments, but dynamic discovery is at odds with the architecture. > > I have a few ideas to mitigate that and help people create instanced > services. Instantiation is a planned feature of the future s6-rc v1 > but it's still a ways away; I am also thinking of adding tools to help > people handle instances with regular s6, amd they may come in the near > future, but there are currently no such helpers, sorry. > > -- > Laurent > -- Automatic-Server AG • Oliver Schad Geschäftsführer Hardstr. 46 9434 Au | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpdOkW5Fkkak.pgp Description: OpenPGP digital signature
Pattern for multiple subservices and dynamic discovery i.e. VPN
Hello everybody, I'm looking for a pattern to solve a problem, where you have to discover dynamically the services you have to start. Examples could be VPN configurations, where you discover the configuration files and start for every file an instance of the VPN service. But it would be nice to have supervision for all of these instances instead of doing it without. Of course I know how to do it without. Is there a pattern around to solve this with s6 and supervision? Best Regards Oli -- Automatic-Server AG • Oliver Schad Geschäftsführer Hardstr. 46 9434 Au | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpex17mIi5A7.pgp Description: OpenPGP digital signature
Re: Supervision on the BSD's
On Sat, 09 Apr 2022 11:36:35 + "Ramarro Marrone" wrote: > I too had been surprised by the lack of supervision in OpenBSD. > > Are the daemons included with the > > distributions so incredibly stable that they don't need supervision > > in order to keep the system functional? > > Yes It's just a question of chance and big numbers. So if you're responsible for a big fleet of things and you have costs to handle every failure, it makes sense to have supervision to reduce these costs. Most users with a few machines never observed any failure ever, independent of the operating system and (server) software. If this would be the argument to decide if supervision is necessary, nobody would need it. And yes, the BSD world tries to be conservative compared to Linux and yes, OpenBSD tends to be the most conservative BSDs related to changes. But I think that isn't the most important thing for decision. I.e. your super stable BSD doesn't help against DoS attacks (read as overload), unstable hardware, misconfiguration of services, packet loss, ... Best Regards Oli -- Automatic-Server AG • Oliver Schad Geschäftsführer Hardstr. 46 9434 Au | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpDQIa0ldnGB.pgp Description: OpenPGP digital signature
Expected behaviour zombie processes
Hi everybody I've observed the following situation: root 490 0.0 0.0 13004 1596 ?SNov05 0:00 s6-supervise lxe root 2738 0.6 0.0 0 0 ?Zsl Nov05 251:13 [lxe] So you see a zombie process. What is the expected behaviour of s6-supervise here? I would expect, that this case is solved immediatly by s6-supervise and a new process is spawned. The observed behaviour was, that no new process was spawned and even s6-svc -r didn't respawn a process. 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 pgpNrD4xc0SqH.pgp Description: OpenPGP digital signature
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: External health Check Process
On Thu, 22 Oct 2020 20:03:17 -0400 Steve Litt wrote: > But most of the other suggestions that in my opinion are just answers > to systemd weenie's "but s6 doesn't have _" arguments, and don't > add nearly enough functionality or convenience for the complexity, or > just plain size added to the user manual, to justify. > > The OP already stated there's a way to do it currently. Why complexify > s6 to do something already doable? I just miss the elegance of the solution: I personally want to model one service with one s6 service. For me it would mean thinking about a wrapper around s6 to get that. Maybe I get now the slew thing. And it's ok to need a wrapper to get useability, but the advertisement of that should be better on the website that you SHOULD use that wrapper (and for me this wrapper should be part of the s6 project). 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 pgpHNHOSShYBI.pgp Description: OpenPGP digital signature
External health Check Process
Hi everybody, we have cases, where processes are still there, but doesn't work anymore. This is a common problem with runtime environments like java or golang, where the memory management might have problems and internal routines doesn't work anymore. That is really a common problem in that area (heap too small, too frequently garbage collection, ...) I know you can model a service in s6, which watches another service and kills it, so in fact the problem is solved outside of s6. But I wanted to ask to develop a feature to get a simple way to model that within s6. Usually it's good enough to call a external command with a timeout and watches exit code. Yes, that means polling but in a datacenter is a polling health check not a big energy problem. Is that something, you can imagine in the future, supporting an external health check? 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 pgp4Uwj7eiJgh.pgp Description: OpenPGP digital signature
Re: The "Unix Philosophy 2020" document
On Sun, 29 Dec 2019 18:07:39 +0200 Alex Suykov wrote: > Er, that whole quoted part, including the last sentence, is about > using cgroups to supervise processes. Not about the use of cgroups in > general. I can't think of any other use cases where cgroup > supervision would be useful, other than for double-forking daemons. Agree. > Also, wrt process supervision, calling it a side effect is bit > misleading. The interfaces are not really made for that kind of use > at all. Strictly speaking, anything doing kill `cat .../cgroup.procs` > is racy and unreliable. Including that runcg tool that I wrote. In > practice, the race is pretty much irrelevant, but it's still there, > inherent to the interfaces. Yes, that is true - but the freezing cgroup can handle that race. As I already mentioned it has corner cases, where a freezed process can't be killed. As far as I read with cgroup v2 this corner case is gone. This whole thing itself (double forking) is a corner case and you should somewhen(!) give an easy interface to catch that case in a supervision toolbox(!) IMHO. You can think of providing that for marketing purposes earlier. However supporting system specific stuff like cgroups is useful (and not just a marketing gag to compete against systemd) and you should support that in a system specific toolbox as part of the supervision suite (read as it is referenced as optional dependency or directly packaged). I don't see a reason to implement such stuff inside of a supervision daemon itself - a system specific toolbox is the right place for that. 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 pgpKdmEP3HB0p.pgp Description: OpenPGP digital signature
Re: The "Unix Philosophy 2020" document
On Sat, 28 Dec 2019 15:05:59 -0300 Guillermo wrote: > Exactly. And that's what nosh's move-to-control-group(1) and > set-control-group-knob(1) do. They are convenience tools invoked by > nosh scripts generated by conversion of unit files (with > 'system-control convert-systemd-units'). Nosh's service manager > doesn't directly deal with cgroups, and neither does its PID 1 > program. Exactly what I would prefer as well - a convenient interface to system specific stuff like linux' cgroups (especially for resource limits, not catching processes) 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 pgpo2UlVDQBdQ.pgp Description: OpenPGP digital signature
Re: The "Unix Philosophy 2020" document
On Sat, 28 Dec 2019 12:29:59 -0600 "Serge E. Hallyn" wrote: > Note that with a few simple scripts, users (and daemons) can do this > all themselves. That is true, but the interface to setup and kill the stuff is a bit ugly or long to write. It makes sense to have an elegant/short way to express that. A library, a command, whatever. It's questionable if the supervisor's linux toolbox should provide something like that, but I would vote for that. 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 pgpkUHQTFyNX9.pgp Description: OpenPGP digital signature
Re: The "Unix Philosophy 2020" document
On Sat, 28 Dec 2019 12:19:30 -0300 Guillermo wrote: > El vie., 27 dic. 2019 a las 20:56, Oliver Schad escribió: > > > > Sorry, I have to correct that a bit: you can use the freezer cgroup > > as I did, but there is no guarantee, that you can successfully kill > > a freezed process. > > You can't? So the 'kill -9' command in your script might not work > while the cgroup's state is "FROZEN"? There are corner cases, where frozen processes can't be killed. Systemd has the race condition implemented. Maybe you can react on that, unfreeze these processes and kill them with the race-condition. > > So you can decide: > > > > 1) race-condition > > 2) unkillallable processes without race-condition > > AFAIK systemd does not (and will not?) use the freezer cgroup > controller, so I guess it's 1) in that case :) Exactly. I've checked the code as well. Read through PID list and kill them one by one with time windows in between, where $SOMETHING could happen. 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 pgpvEWxUTTKCb.pgp Description: OpenPGP digital signature
Re: The "Unix Philosophy 2020" document
On Sat, 28 Dec 2019 16:04:53 +0200 Alex Suykov wrote: > Sat, Dec 28, 2019 at 01:57:25PM +1100, eric vidal wrote: > > > Well, for me, cgroups is clearly a lack to s6. Using it for every > > process like systemd do have no sense, but in some case it can be > > useful to protect e.g an "over-eat" allocation memory by a program > > (in particular over a server). > > Minor note on this. Resource limiting with cgroups does not require > any explicit support from s6, or any external tools for that matter. An external tool is always enough, for limitting and killing. But it could be helpful to have system specific tooling in small tool boxes, so that we would have s6 s6-linux s6-bsd ... -- 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 pgpJe1bIa7UA7.pgp Description: OpenPGP digital signature
Re: The "Unix Philosophy 2020" document
On Sat, 28 Dec 2019 15:37:35 +0200 Alex Suykov wrote: > The reason I think it's mostly useless is because the only use case > for cgroup supervision is supervising double-forking daemons, which > is not a very smart thing to do. A much better approach is to get rid > of double-forking and then just directly supervise the resulting long > running process. > I can't think of any other cases where it would be useful. I definitly have to correct you: cgroups are *NOT* designed to catch wild forking processes. This is just a side-effect ot them. The purpose is to control resource limits, like CPU, RAM, Disk I/O and so on. So for linux it would definitly make sense to have an interface to the full feature set. 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 pgpibEWGc65QS.pgp Description: OpenPGP digital signature
Re: The "Unix Philosophy 2020" document
On Sat, 28 Dec 2019 00:54:07 +0100 Oliver Schad wrote: > Disclaimer: this has race-conditions by design. systemd has them as > well. No, they don't say that of course. You can't read the tasks > atomically and change their state to stopped, freeze or whatever. So > they always could fork away. Sorry, I have to correct that a bit: you can use the freezer cgroup as I did, but there is no guarantee, that you can successfully kill a freezed process. So you can decide: 1) race-condition 2) unkillallable processes without race-condition -- 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 pgpxtDHqyWIuU.pgp Description: OpenPGP digital signature
Re: The "Unix Philosophy 2020" document
On Fri, 27 Dec 2019 12:32:27 + "Laurent Bercot" wrote: > As for cgroups-related chainloaders, I could probably write some in > s6-linux-utils, but wasn't the cgroups interface designed to make > sure those operations are trivial to implement as small scripts? I changed in the past sysv init scripts in exactly that way, that they created a cgroup first at start and killed all processes within that cgroup at the end. That where 5? lines of shell. You could provide that system wide, if you would offer some include mechanism (pre-run, post-stop) or within the run/finish scripts just include a shell library. In the first place it would be ok, to have the name of the service available as an identifier for the cgroup. A random name would only work if you persist it somewhere and have to manage the clean-up - I would prefer to use the directory's name of the run script. Is it available through a environment? Something like: ## run ## CGROUP_BASE_DIR=/sys/fs/cgroup/freezer cgroup=$run_dir mkdir $CGROUP_BASE_DIR/$cgroup echo $$ > $CGROUP_BASE_DIR/$cgroup/tasks # exec or include exec do_the_real_stuff ## finish ## CGROUP_BASE_DIR=/sys/fs/cgroup/freezer cgroup=$run_dir state_file=$CGROUP_BASE_DIR/$cgroup/freezer.state echo FROZEN > $state_file i=0 while ! grep FROZEN $state_file > /dev/null; do let i=$i+1 sleep 0.1 if [ $i -gt 100 ]; then break fi done kill -9 $(cat $CGROUP_BASE_DIR/$cgroup/tasks) Disclaimer: this has race-conditions by design. systemd has them as well. No, they don't say that of course. You can't read the tasks atomically and change their state to stopped, freeze or whatever. So they always could fork away. What you can do is repeat the killing/freezing/stopping until it succeeds (mabye never). 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 pgpnNc8oL23OG.pgp Description: OpenPGP digital signature
Re: The "Unix Philosophy 2020" document
> On Sun, Nov 17, 2019 at 02:26:44PM +0800, Casper Ti. Vector wrote: > > I have written a dedicated "s6/s6-rc vs systemd" post on the Gentoo > forums, which I believe have included convincing responses to most > common arguments by systemd proponents: > <https://forums.gentoo.org/viewtopic-t-1105854.html>. OMG - how much work was that? Great! 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 pgpFZGQcrwsOG.pgp Description: OpenPGP digital signature
Re: s6 usability
On Mon, 23 Dec 2019 10:15:11 + Jonathan de Boyne Pollard wrote: > Oliver Schad: > > > A booting tools should be in /bin - full stop! > > > > That is historically untrue. The real world has not actually worked > in the way that some people think. Sorry, this is a historical explanation of some things - is this a history course here? That is *not* what you would expect today. Scripts for system initialization (a special case) should find all tools in /bin, because it's in always in the path (always today). To put tools for a lot of scripts somewhere(!) would mean, that all scripts have a method to find these tools or would mean to add more directories to PATH. Because the maintainer of these scripts are completely distributed (it's not one small team, which writes boot/start scripts), it's crazy to do something else than put everything in /bin. If you would say, that this is not true, then we can discuss where we should place cp, mv, ls - maybe in /usr/lib/gnu/? Really? Important scripting tools should always be in /bin or /usr/bin - /bin for boot, /usr/bin for later stages is ok. 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 pgpU0oY0kJ2ci.pgp Description: OpenPGP digital signature
Re: s6 usability
On Sun, 22 Dec 2019 23:20:03 + "Laurent Bercot" wrote: > I don't know, why does Unix like to have its binaries in /bin? Why > does PATH exist? What is the nature of an executable? You have two > hours. Sorry, this discussion is crazy: Laurent provides a basic booting tools with his toolchain. A booting tools should be in /bin - full stop! However - what is the concrete suggestion from the Debian guys what Laurent should do? On top, it makes sense to start a community integration program to fullfill distro requirements. So that would include public test and build infrastructure and pre-packaging stuff. I can support that with free hosting for building and testing, i.e. I can provide a public gitlab with build and test pipelines. 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 pgprAyE0rdVxz.pgp Description: OpenPGP digital signature
Re: The "Unix Philosophy 2020" document
Hi Casper, thank you for the effort putting things together. I was asking myself some questions. What is the target group? What is the exact purpose of that document? For systemd I have a more practical approach to discuss: 1) how many config statements are there? 2) how many cases exist, which you have to work around (practical setups, where a config statement is missing or do the wrong thing) 3) how many bugs/feature requests are opened over time and how long does it take to solve them? 4) how big is the memory footprint and for which systems this is too much? 5) how many lines of code? So you would have metrics - especially if you compare them to other solutions. If you want to have more food, make more metrics (call graph complexity or whatever). But there are simple metrics, which shows the result(!) of the design. Talking about the design itself is really a personal opinion otherwise and very lengthy and needs a lot of knowledge to follow. For the philosophy itself there are some parts missing in my opinion: what does that really mean what you're talking about in practical solution? Is there a practical approach anywhere, interface definition, architecture? You describe a few patterns ok - but they are really common. I don't get really, which people would help this document. Maybe that thing is missing: if somebody would like to build a modern UNIX: what are practical steps to achieve it? Which tools, which interfaces (kernel, userland) are needed? Best Regards Oli BTW: I can't really see images inside the PDF -- 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 pgp3IjVvwXotU.pgp Description: OpenPGP digital signature
Re: s6-linux-init: Actions after unmounting filesystems
On Sun, 18 Aug 2019 16:28:40 -0300 Guillermo wrote: > I know that there are people that have the rootfs on an LVM logical > volume or a LUKS encrypted volume, yes. However, those are specialized > setups. In some distributions it's a default AFAIR. I know a lot of people who do that on workstations and servers. More specialized are non-LUKS crypto setups which works with an external USB stick which is removed after start for plausible denial of knowledge of a crypto setup. I know some crypto setups which broke through systemd. BTW: a good sign to do it another way is that our systemd friends are thinking about it. ;-) 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 pgpRwXCZd9buG.pgp Description: OpenPGP digital signature
Re: emergency IPC with SysV message queues
Sorry for my side note: but I have to say, that these discussions are really great! I thought it would be just boring as it started. But from my side I can tell you, that I learn a lot because you talk about reasons to do something or to let something. It's far better than "I believe" and "I like". Thank you very much for sharing your reasons. 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 pgpF5g_fGejkl.pgp Description: OpenPGP digital signature
Re: interesting claims
On Wed, 15 May 2019 13:22:48 -0400 Steve Litt wrote: > The preceding's true for you, but not for everyone. Some > people, like myself, are perfectly happy with a 95% reliable system. I > reboot once every 2 to 4 weeks to get rid of accumulated state, or as > a troubleshooting diagnostic test. I don't think I'm alone. Some > people need 100% reliable, some don't. That is a strange point of view: there might be people who doesn't need computers at all. So we shouldn't program anything? So if there are people outside who needs a higher quality and Laurant wants to target them, then he needs to deliver that and it makes sense to argument with that requirement. 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 pgpg5pz6vlCk6.pgp Description: OpenPGP digital signature
S6 readiness
Hi everybody, because we have that topic: in the case a service doesn't support itself the interaction with readiness, a watching peace of code would be nice (checking open port, checking HTTP call, ...). How to model that with s6? 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 pgpMuknz_sn5L.pgp Description: OpenPGP digital signature
Re: Update on the progress of slew development
On Tue, 19 Mar 2019 20:42:39 +0800 "Casper Ti. Vector" wrote: > On Sun, Mar 17, 2019 at 03:30:02PM +0100, Oliver Schad wrote: > > https://gitlab-2.asag.io/snippets/7 > > A closer look at this snippet reveals that most changes therein are: > 1. Customisations of `s6-log.rc', probably modifying the logging user. Exactly - it doesn't make sense for us to have for every service it's own logging user. So I defined a common log user. > 4. Other regular customisations similar to what I showed yesterday. I had to change the some files in init/ https://gitlab-2.asag.io/snippets/8 Some changes in lib/ to have a working update: https://gitlab-2.asag.io/snippets/9 killall5 didn't work at all, the "sync" was added just in case mounting read-only doesn't work, emtpyenv kills the container environment, which is needed, clock adjustment doesn't work inside a container. Rest later ... 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 pgpvaXTZ8ZUMt.pgp Description: OpenPGP digital signature
Re: Update on the progress of slew development
Hi Casper, thanks for the project. I have to say, that I didn't get really, that the implementation of jobs is a goal of slew, because most jobs didn't fit for us. So I understood the whole project as a nice integration layer for s6, but we changed every unit, changed reboot, halt, the build-script and so on. So in the end Slew was great to understand, how s6 could be integrated as a pattern. But the units/scripts itself didn't work for us. https://gitlab-2.asag.io/snippets/7 So may I ask directly: is the plan to provide scripts/units for everyone, which works almost out of the box? 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 pgpR0odUN7qXE.pgp Description: OpenPGP digital signature
