From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3252 invoked from network); 11 Aug 2021 11:06:13 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 11 Aug 2021 11:06:13 -0000 Received: (qmail 25629 invoked by uid 89); 11 Aug 2021 11:06:35 -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 25618 invoked from network); 11 Aug 2021 11:06:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4bh0E92eTHjXPV5G97Jp4cA4RkFsC9IJebcOUz4YLUY=; b=FebeKpHQWC1Gokqne+Fma5uXbtfJLHnz1POk1rigp1vkMjW2vaFEEXsJyAzLdkYzxT S8jegla/zFbKBHxKdMFiyU2go2rlPAD/jfxUdwKsGwyLi+/rXyPvgqkN0MKNTtUy0Hyo jNL7frICJIaC0lDHTJqKoZyyCkW8Uil0HCskpj7p62yEpYf7hprrR9xdVj7sQeyV9zza Sd8sQ4GiRQzE3cEaNLPxm5CBfavTtzjdBzfdmgg9Vqg/JKz1d1F9eqkYQurH8DOYk04h XGUtv6CLLk9lfVLepgVJ7F4r1IRq9oWuagCvVTeWbFc/reFKvMMOYxuvwIheQqwCeGhg 4dhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4bh0E92eTHjXPV5G97Jp4cA4RkFsC9IJebcOUz4YLUY=; b=SwuFQJnkvDuhxg4+u29calWg+GkHGyfbeve4KcBYUDgoyTKNviEkcdeoaZ9AAlpAfw l91lMYVNYJ7Ad6am8Qx3FgROzDSYcLr+R3UenvUd69HPHKuQpHIu5o4R94Uf9U2RHusY bEOdQOVVxSr9D9WMKROkkbT4rV0v2yejeCtztBAtCDYye0tE+FAWvprVsaHV1tr2H1zC dW92C/3K5dbYczlF/1CZMWxNx/ogq9xIoote2+SVu38UIkQnQjsWbIauoOTMVlCq3D49 mT/zOfj1Tlmd0cbzDPLfDCJAXoo1VdC357nw6JBa/zXcA246LoSHuna6BTJQ/7vspzif iWcA== X-Gm-Message-State: AOAM533Ndi5ete1/G5YrOGI7CGdulDaaEv1IRBawlWMIpj5A3gWPlp7D kSWPu5pJ51YQsZ7oTf/SkFfCslcCX9JjO6SuuXWLAFQQFsI= X-Google-Smtp-Source: ABdhPJxDrtkBdSUeligq//Fj1D4IWDgxxcU3XthV9ShOLcP2K1mYl1tQH416mHyFM2XnWpT3QtQJY0+bYu92seNgPTc= X-Received: by 2002:a1c:1b92:: with SMTP id b140mr3084820wmb.113.1628679967430; Wed, 11 Aug 2021 04:06:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arjun D R Date: Wed, 11 Aug 2021 16:35:56 +0530 Message-ID: Subject: Re: S6 Queries To: Laurent Bercot Cc: supervision@list.skarnet.org Content-Type: multipart/alternative; boundary="000000000000e95e0f05c9469a74" --000000000000e95e0f05c9469a74 Content-Type: text/plain; charset="UTF-8" Thanks Laurent for the detailed explanations. We did a bootup speed comparison between S6 and systemd. S6 is able to boot up slightly faster than systemd. Actual result is 4-4.5% faster but we were expecting something near to 20%. Ours is a bit complex setup with more than 140 services (includes a lot of long run services and a lot of dependencies). The main advantage in systemd is, it starts many critical processes very quickly since it has no dependency to logging services. We collect the logs from journalctl and store it in log files. Whereas in S6, the critical services start up is a bit delayed since it has to depend on logging services which in turn depends on other services (responsible for backing up the previous logs). Arjun On Mon, Aug 2, 2021 at 1:57 PM Laurent Bercot wrote: > >1. In systemd, the services are grouped as targets and each target depends > >on another target as well. They start as targets. [ex: Reached > >local-fs.target, Reached network.target, Reached UI target,...]. Is there > >any way in S6 to start the init system based on bundles? > > Yes, that is what bundles are for. In your stage 2 boot script > (typically /etc/s6-linux-init/current/scripts/rc.init), you should > invoke s6-rc as: > s6-rc change top > if "top" is the name of your default bundle, i.e. the bundle that > contains all the services you want to start at boot time. You can > basically convert the contents of your systemd targets directly into > contents of your s6-rc bundles; and you decide which one will be > brought up at boot time via the s6-rc invocation in your stage 2 > init script. > > > >2. Are there any ways to have loosely coupling dependencies? In systemd, > we > >have After=. After option will help the current service to start after the > >mentioned service (in after). And the current service will anyway start > >even if the mentioned service in After fails to start. Do we have such > >loosely coupled dependency facility in S6? > > Not at the moment, no. The next version of s6-rc will allow more types > of dependencies, with clearer semantics than the systemd ones (After=, > Requires= and Wants= are not orthogonal, which is unintuitive and causes > misuse); but it is still in early development. > > For now, s6-rc only provides one type of dependency, which is the > equivalent of Requires+After. I realize this is not flexible enough > for a lot of real use cases, which is one of the reasons why another > version is in development. :) > > > >3. Is there any tool available in S6 to measure the time taken by each > >service to start? We can manually measure it from the logs, but still > >looking for a tool which can provide accurate data. > > Honestly, if you use the -v2 option to your s6-rc invocation, as in > s6-rc -v2 change top > and you ask the catch-all logger to timestamp its lines (which should > be the default, but you can change the timestamp style via the -t > option to s6-linux-init-maker) > then the difference of timestamps between the lines: > s6-rc: info: service foo: starting > and > s6-rc: info: service foo successfully started > will give you a pretty accurate measurement of the time it took service > foo to start. These lines are written by s6-rc exactly as the > "starting" or "completed" event occurs, and they are timestamped by > s6-log immediately; the code path is the same for both events, so the > delays cancel out, and the only inaccuracy left is randomness due to > scheduling, which should not be statistically significant. > > At the moment, the s6-rc log is the easiest place to get this data > from. You could probably hack something with the "time" shell command > and s6-svwait, such as > s6-svwait -u /run/service/foo ; time s6-svwait -U /run/service/foo > which would give you the time it took for foo to become ready; but > I doubt it would be any more accurate than using the timestamps in the > s6-rc logs, and it's really not convenient to set up. > > > >4. Does the S6 init system provide better boot up performance compared to > >systemd ? One of our main motives is to attain better bootup performance. > >Is our expectation correct? > > The boot up performance should be more or less *similar* to systemd. > The code paths used by the s6 ecosystem are much shorter than the ones > used by systemd, so _in theory_ you should get faster boots with s6. > > However, systemd cheats, by starting services before their dependencies > are ready. For instance, it will start services before any kind of > logging is ready, which is pretty dangerous for several reasons. As a > part of its "socket activation" thing, it will also claim readiness > on some sockets before even attempting to run the actual serving > processes (which may fail, in which case readiness was a lie.) > Because of that, when everything goes well, systemd cuts corners that > s6 does not, and may gain some advantage. > > So all in all, I expect that depending on your system, the difference > in speed will not be remarkable. On very simple setups (just a few > services), systemd's overhead may be noticeable and you may see real > improvements with s6. On complex setups with lots of dependencies, s6 > might still have the speed advantage but I don't think it will be > anything amazing. The real benefit of s6 is that it achieves > roughly the same speed as systemd *while being more reliable and > predictable*. > > If you actually make bootup speed comparisons between systemd and s6, > please share them! I am interested in that kind of benchmarks, and > I'm sure the community would like to see numbers as well. > > -- > Laurent > > --000000000000e95e0f05c9469a74--