Re: Update: rpm package for utmps, skalibs.

On Mon, Apr 01, 2024 at 12:46:27PM +, Laurent Bercot wrote: > This means that your execline package cannot run execline scripts that > use cd, umask or wait. It may work for you, but it is not suitable as a > general audience package. Certainly. I avoid RedHat-like systems except when

Re: Update: rpm package for utmps, skalibs.

On Mon, Apr 01, 2024 at 07:26:22PM +0800, qi wang wrote: > Could you provide some suggestion? Or does anyone has some experience > on that? In my (admittedly ugly) package, I simply delete execline's `cd' and `umask'; `wait' is renamed to `execline-wait', just like `execline-cd' and

Re: Update: rpm package for utmps, skalibs.

On Mon, Apr 01, 2024 at 09:09:52AM +, Laurent Bercot wrote: > I haven't looked in detail, but I'm not sure why you want everything > in one single RPM. The packages he makes are not monolithic; the package by me, noted in earlier messages, is monolithic, due to historical reasons and a lack

Re: is there any rpm package for utmps, skalibs?

On Thu, Mar 28, 2024 at 03:58:24AM +0900, Dominique Martinet wrote: > Also, if I'm reading this correctly it actually make /usr/bin 777 > because of flawed logic (stat -c %a /bin instead of %{_bin} (= /usr/bin); > given /bin is normally a symlink to /usr/bin that stat will return 777 > and the

Re: is there any rpm package for utmps, skalibs?

On Wed, Mar 27, 2024 at 07:43:24PM +0900, Dominique Martinet wrote: > You should never need sudo in the install section of a spec file -- > you install to %{buildroot}, not directly to the system's bin/lib > directories! It is moving files *into* %{buildroot}, not *out of*. The converse is done

Re: is there any rpm package for utmps, skalibs?

On Wed, Mar 27, 2024 at 01:41:49PM +0800, ericwq057 wrote: > I search fedora39/centos 7, there is no available rpm package for > utmps or skalibs. Asked google, there is only a very old (1.6) skalibs > rpm spec available: https://github.com/imeyer/skalibs-rpm. Is there > any plan to support rpm

Re: posix_spawn (was: Bugs with execline/s6 documentation and skalibs functions using posix_spawn())

On Thu, Jun 29, 2023 at 11:04:33AM +, Laurent Bercot wrote: > Indeed, /dev should work; but using it still makes me queasier than > crafting a nonexistent path. Actually deliberately supplying a directory to posix_spawn*() is a slightly deeper test, as the path exists but is unexecutable.

Re: posix_spawn (was: Bugs with execline/s6 documentation and skalibs functions using posix_spawn())

On Thu, Jun 29, 2023 at 08:21:19AM +, Laurent Bercot wrote: > POSIX doesn't mandate any path other than /dev/null and /dev/console > and I'd rather not try executing them, who knows what weird permissions > they may have on obscure OSes. Actually I mean a *directory* that is guaranteed to

Re: posix_spawn (was: Bugs with execline/s6 documentation and skalibs functions using posix_spawn())

I have realised that a simpler unexecutable path can be, for example, /etc (is it mandated in POSIX?); this can save the mkstemp() call in the sysdep test. (And frankly I personally do not really find it much worthwhile to introduce this amount of complexity for the broken dependency of a quite

Re: posix_spawn (was: Bugs with execline/s6 documentation and skalibs functions using posix_spawn())

On Wed, Jun 28, 2023 at 09:40:48PM +, Laurent Bercot wrote: > I pushed a workaround to the skalibs git. > Could you please try a build on a machine that exhibits the early > return behaviour and tell me if > - the behaviour is correctly detected by ./configure (the last sysdep) Yes, after

Re: Bugs with execline/s6 documentation and skalibs functions using posix_spawn()

On Wed, Jun 28, 2023 at 01:33:57AM +, Laurent Bercot wrote: > They're not the only possible behaviours: for instance, [1] shows that > under some buggy qemu, posix_spawn() always returns early. That seems to at least inadvertently comply with posix_spawn(3)... -- My current OpenPGP key:

Re: Bugs with execline/s6 documentation and skalibs functions using posix_spawn()

On Tue, Jun 27, 2023 at 09:27:17PM +, Laurent Bercot wrote: > Testing the behaviour may be challenging, however, because I suspect > the CentOS 7 implementation of posix_spawn() is just racy, and they > simply documented that they don't care. Actually I copied the fragment of posix_spawn(3)

Re: Bugs with execline/s6 documentation and skalibs functions using posix_spawn()

On Tue, Jun 27, 2023 at 08:50:35AM +, Laurent Bercot wrote: > I believe the correct setting is actually KillMode=mixed; and the > ExecStop= line is incorrect as well since ExecStop expects a synchronous > command, not an asynchronous one. Better let systemd just send a SIGTERM > to s6-svscan,

Re: Bugs with execline/s6 documentation and skalibs functions using posix_spawn()

On Tue, Jun 27, 2023 at 10:16:10AM +0800, Casper Ti. Vector wrote: > * The child_spawn*() family of functions, [...] Well, just found another one when handling the above issue: * `flags.html' from skalibs references `--enable-sysdep-devurandom', which should now be `--with-sysdep-devuran

Bugs with execline/s6 documentation and skalibs functions using posix_spawn()

* In `trap.html', there is a reference to the removed `timeout' keyword. * In `s6-svscan-not-1.html', the systemd unit (traumatic experience with it, as you may easily expect) lacks a `KillMode = process'. * The child_spawn*() family of functions, depending on using posix_spawn or not,

Re: [skaware] non privileged user oneshots/services launched by root not requiring the user to login 1st (like systemd @user ones) support

On Thu, Oct 28, 2021 at 06:17:52PM -0600, Javier wrote: > I use s6 on artix gnu+linux, and I think I'm missing support for > oneshots/services like the systemd @user ones. Those are still > launched automatically when the system (not the user) starts. The following may help as well:

Re: UCSPI-TLS for s6-networking?

On Mon, Nov 16, 2020 at 02:05:27PM +, Laurent Bercot wrote: > If I needed to write an SMTP server that supports STARTTLS, the way > I would do it would be the following: I have also been thinking about a minimal implementation of STARTTLS MX (I think this may be the only hard-to-remove

Re: Unexpected behavior when updating exclusive policy package

On Tue, Oct 20, 2020 at 02:53:50PM +0200, Oliver Schad wrote: > But because it could cause a production problem (think about a master > SQL server in a high traffic situation wich kills all his caches during > restart and maybe will be down for minutes), I think there should be a > way to give

Re: The "Unix Philosophy 2020" document

(I guess discussions about this document is probably destined to be off-topic on the skaware list, so further public mail in this thread will only be posted to the supervision list; sorry for the disturbance.) On Fri, Sep 27, 2019 at 04:38:16PM +0800, Casper Ti. Vector wrote: > Altho

The "Unix Philosophy 2020" document

On Sun, Sep 01, 2019 at 05:11:57PM +0800, Casper Ti. Vector wrote: > I roughly see. Other programs, like date(1) and conky, do seem to > output the correct time after resuming, but I (at least recently, and > you will know why in roughly two to four weeks) really do not have time > to

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

On Sun, Sep 01, 2019 at 10:18:42PM +, Laurent Bercot wrote: > Yes, it does. But --enable-monotonic is a bad idea for long-lived > processes that need timestamping. I need better clock interfaces > in skalibs, the current ones don't allow a run-time selection > between clocks. Hopefully I can

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

On Sun, Sep 01, 2019 at 10:54:44PM -0300, Guillermo wrote: > OK. Going back to Casper's problem, I remember from old posts that he > is using Void, Void packages a libskarnet built with > --enable-monotonic, and the man page says that CLOCK_MONOTONIC does > not count time that the system is

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

On Sun, Sep 01, 2019 at 08:41:33AM +, Laurent Bercot wrote: > Short answer: no, the system needs to readjust the system clock when > resuming from suspension/hibernation; it's a problem not only with > s6-log, but with every program using the system clock, so the problem > should be fixed

s6-log timestamp bug after resuming; Plan 9 $path and /package

1. After resuming from suspension or hibernation, s6-log no longer shows the correct timestamp. Can this be fixed? Thanks. 2. Some days ago I stumbled upon [1], and found it possibly a much less intrusive alternative to a centralised registry for command names [2]. Any thought on

Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

On Mon, Jun 10, 2019 at 11:10:13PM -0300, Guillermo wrote: > /etc/nsswitch.conf is 'owned' by sys-libs/glibc, and Gentoo's default > comes directly from the libc's source package: So Gentoo follows the upstream more closely, and the upstream default would now result in the problem. I think this

Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

On Sun, Jun 09, 2019 at 05:28:49PM -0300, Guillermo wrote: > /etc/nsswitch.conf, which I don't recall having ever modified, says: > group: db files Try using `qfile -o' to find the owner, and subsequently how it should originally have been? (I used Gentoo for several years before migrating to

Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

On Mon, Jun 03, 2019 at 08:36:00AM +, fungal-net wrote: > Void (both glibc and musl) have had the whole s6 suite and skarnet libs > on its repositories for all (xx) architectures. s6-rc doesn't work out > of the box though (tried and tried, I don't know enough to get it > working). I can

Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

On Sun, Jun 02, 2019 at 12:02:04PM -0300, Guillermo wrote: > Do you happen to build skarnet.org packages statically linked to musl > on those Void machines, or do you let them link to the distribution's > libc? On both Alpine and Void, I use the stock packages for skaware from the distros, and

Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

On Sat, Jun 01, 2019 at 11:55:57PM -0300, Guillermo wrote: > Sooo... thoughts? Does anyone else use a sufficiently recent version > of GNU libc and experience the same? On my machine using Void with glibc 2.29 since 20190305, I never encountered this issue. I can confirm the behaviour you

Re: S6 integration in mainstream linux distributions

On Sun, Mar 17, 2019 at 03:21:43PM +0100, Oliver Schad wrote: > I completely understand the purpose of execline but for server systems, > which allocates more than 1 GB RAM regulary and running on modern x86 > CPUs, saving such resources is not needed for us(!). Which is also why I usually

Re: S6 integration in mainstream linux distributions

On Fri, Mar 15, 2019 at 02:33:50PM +0100, Oliver Schad wrote: > We found the project "slew"[1] which offers a nice way to manage oneshot > services, cause execline doesn't offer the things we want to re-use > today. A history note: once a friend of mine, when introduced to execline, told me about

Re: S6 integration in mainstream linux distributions

On Fri, Mar 15, 2019 at 02:33:50PM +0100, Oliver Schad wrote: > The next question was the long-term strategy with systemd: we have 2 > approaches > > 1) mix systemd (PID 1) to use the boot phase (especially one shots) > and later (after system initialization) use s6 to manage all services. > 2)

Re: On lh-bootstrap and mkroot

On Mon, Sep 03, 2018 at 08:47:32PM +, Laurent Bercot wrote: > I have asked landley before whether he shared my interests for weird > things such as using less resources than the shell, or supervision > systems. His answer was a resounding and unambiguous "no". His interests > are focused on

Re: On lh-bootstrap and mkroot

On Mon, Sep 03, 2018 at 02:34:41PM -0400, Zach van Rijn wrote: > The ones in [3] are not stripped, and that accounts for most of > the size discrepancy. I will ask Rob to consider adding that to > his 'mcm-buildall.sh' script. I simply build/host binaries. Thanks for explanation; now I

On lh-bootstrap and mkroot

Although I have tried neither of lh-bootstrap or mkroot [1], I noticed that the toolchains of the former is nearly one magnitude smaller than those [2] of the latter, while both seem to be based on musl and statically linked. [1] . [2]

Re: Question about enable-absolute-paths option

On Sun, Sep 02, 2018 at 11:17:20PM +0800, Shengjing Zhu wrote: > The actual reason is that I can't afford time to argue with other > developers. When I ask on debian-devel list, at least someone is > object to this[1]. I'd to admit that I'm not good at argument. The > simple solution I see is to

Re: Question about enable-absolute-paths option

On Sun, Sep 02, 2018 at 02:12:47PM +0800, Shengjing Zhu wrote: > Thanks for this note, I haven't looked at these packages. At first I > thought execline binaries will only be called inside execlinep > scripts. Could you give some examples that s6 calls these binaries > directly except exelinep?

Re: execline

Some relatively minor points to add: On Tue, Apr 10, 2018 at 11:12:30AM +0800, Casper Ti. Vector wrote: > * Perferably, support something like scsh Though I like the idea of scsh, I still find it slightly large; I think a set of suitable macros and library functions for Chibi might be a bet

Re: [announce] execline-2.4.0.0

On Sat, Mar 31, 2018 at 11:15:43PM +, Laurent Bercot wrote: > So, with user-friendliness as a major goal, with version 2.4.0.0, > some execline commands have changed names. One step closer to scsh [1] for execline ;) Any plan for backward compatibility or at least a transition phase? [1]

Re: s6-svscan - controlling terminal semantics and stdin use

On Tue, Jan 02, 2018 at 08:33:18AM -0800, Earl Chew via skaware wrote: > I do not think that my suggestion of placing the children of s6-svscan in a > separate process group from s6-svscan itself changes any of these > objectives. Each service would continue to apply its own session leader role >

Re: s6-svscan - controlling terminal semantics and stdin use

On Mon, Jan 01, 2018 at 07:53:39PM -0800, Earl Chew via skaware wrote: > If instead, I start s6-svcscan at the terminate and terminate it with ^C > (SIGINT), what I observe is that the child s6-supervise processes > terminate abruptly and their child service processes are orphaned. I > think the

Re: SIGFPE in s6-rc-init 3.0.0 etc,...

On Fri, Dec 15, 2017 at 12:08:56PM +, Laurent Bercot wrote: > The SIGFPE sounds very weird because s6-rc doesn't use floating point > anywhere, but if it's hitting undefined behaviour then everything is > possible. >From the `FPE_INTDIV' part of , it seems

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

Will there be a plan to add something roughly isomorphic to libudev? On Mon, Oct 23, 2017 at 08:02:33AM +, Laurent Bercot wrote: > mdevd is an uevent manager reading a sequence of uevents and handling > them without forking, that understands the full /etc/mdev.conf format. -- My current

Re: .env file handling

See also rc(1) :) On Tue, Oct 24, 2017 at 10:55:28PM +0200, Guillaume Perréal wrote: > The scoping might be a bit challenging, but the variable substitution system > is royal. I do not constantly ask myself "what will happen if this variable > contains a space, or a quote ?". -- My current

Re: PEBKAC prevention with s6-rc

Thanks; I think these fixes would prevent most people from making the same mistake I made :) On Sat, Sep 30, 2017 at 07:37:26PM +, Laurent Bercot wrote: > Whoops! Sorry, fixed. :) -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E

Re: PEBKAC prevention with s6-rc

I see; I think this version is OK, but the update seems to be absent from the git repository? On Sat, Sep 30, 2017 at 02:54:56PM +, Laurent Bercot wrote: > https://skarnet.org/software/s6-rc/upgrade.html ? -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077

Re: PEBKAC prevention with s6-rc

I think the update makes it clear enough to me, but I did not find any update on the recompilation issue. On Sat, Sep 30, 2017 at 01:24:46PM +, Laurent Bercot wrote: > Please tell me if it makes things clearer for you, or if something more > is needed. -- My current OpenPGP key:

Re: [announce] skarnet.org August 2017 release

Does this mean something interesting with bugfixes in other packages? ;) On Mon, Aug 28, 2017 at 11:25:58PM +, Laurent Bercot wrote: > - Bugfixes. (No security issue involved.) -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E

Re: Problems with recent versions of s6-rc

I just found myself being extremely careless this time: when I said "the alpine testing repository", I really meant `edge/testing', but s6-rc v0.2.1.1 should be in `edge/main', so probably I just installed s6-rc v0.2.0.1 from `v3.6/main', and rediscovered the original problems with the old alpine

Re: Problems with recent versions of s6-rc

The s6-rc-compile segfault and the s6-rc failure still occur with `s6-rc 0.2.1.1-r0' from the alpine testing repository. -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Problems with recent versions of s6-rc

Thanks. Seems I need to pin the s6-related packages at alpine 3.5.x on my servers for a longer time... On Sun, Jun 04, 2017 at 11:21:30AM +, Laurent Bercot wrote: > We have confirmed that it is an Alpine problem. We're not sure > exactly where the problem occurs (the usual suspect, grsec,

Re: Problems with recent versions of s6-rc

Hello, is there any progress on this issue? On Fri, May 26, 2017 at 04:00:06AM +, Laurent Bercot wrote: > Tomorrow I'll report that to the Alpine devs, and investigate what > could have gone wrong. And I'll have to either pay more attention to > Alpine quality control, or drop maintenance

Re: difference between bundles and dependencies in s6-rc

. On Fri, May 26, 2017 at 03:58:15PM -0500, Brett Neumeier wrote: > If there is a functional difference -- what is it? -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07

Re: Problems with recent versions of s6-rc

On Fri, May 26, 2017 at 12:15:39AM +, Laurent Bercot wrote: > When it's about debug information such as strace outputs ;) > Except that when you send a file to a mailing-list Well this is the problem I neglected: it is

Re: Problems with recent versions of s6-rc

Well I think pastebins really tend to be unreliable (most importantly, content disappearing at unexpected time), so small files (whether text or binary, as long as they are relevant) are best posted directly to the mail list; and since compression saves space, tarballs and zipballs are suitable

Re: Problems with recent versions of s6-rc

, 2017 at 09:19:26PM +0800, Casper Ti. Vector wrote: > attached is the log. -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C rc-log.tgz Description: GNU Unix tar archive

Re: Problems with recent versions of s6-rc

After reboot-looping a test VM for many times, this is also reproduced successfully; attached is the log. On Thu, May 25, 2017 at 09:07:26PM +0800, Casper Ti. Vector wrote: > The issue with `s6-rc' seems to be difficult to reproduce when `s6-rc' > is debugged by strace, so I am unable to p

Re: Problems with recent versions of s6-rc

Not even in a VirtualBox VM? Seems more interesting than I thought... Attached is the logs of `s6-rc-compile' for the three cases. The issue with `s6-rc' seems to be difficult to reproduce when `s6-rc' is debugged by strace, so I am unable to produce a log for it now. On Thu, May 25, 2017 at

Re: Problems with recent versions of s6-rc

On Thu, May 25, 2017 at 10:17:22AM +, Laurent Bercot wrote: > All the problems you report should be fixed with skalibs-2.5.1.1, which > should already be available in Alpine. Are you still experiencing issues > with skalibs-2.5.1.1 ? I experienced this when updating Alpine from v3.5.2 to

Re: Problems with recent versions of s6-rc

arning: unable to start start service s6rc-oneshot-runner: command > exited 111 On Thu, May 25, 2017 at 12:58:30PM +0800, Casper Ti. Vector wrote: > * Incompatibility of the compiled database: s6-rc commit 543c1405 breaks > the backwards compatibility of the compiled service

Problems with recent versions of s6-rc

* s6-rc-compile segfault: boot up a VirtualBox VM with (for reproducibility) `alpine-standard-3.6.0-x86_64.iso', log in as root (no password needed), install s6-rc (v0.2.0.1 as of now) from the Alpine v3.6 repository, uncompress the attached tarball, and run $ rm -rf compiled &&

Re: Some glitches on skarnet.org

By "full upgrade", I actually meant "no downgrading" instead of "disabling HTTP", so I take your answer as a "yes" :) After some summarising, I found the list of skarnet.org self-links to be fairly trivial: * Links in skarnet.org packages: I note that `skarnet.org' links have just been fixed,

Re: Using execline in place of shell for s6/s6-rc setup: environment variables?

Something strange happened to my previous mail: the `SHA512SUMS.asc' file only had one line saying `Version: 1'; perhaps a problem with mutt. The correct version is now attached. And I am very sorry for these spammy mails :( On Sat, May 20, 2017 at 12:51:13PM +0800, Casper Ti. Vector wrote

Re: Using execline in place of shell for s6/s6-rc setup: environment variables?

:( On Sat, May 20, 2017 at 12:51:13PM +0800, Casper Ti. Vector wrote: > Attached are their checksums (plus that for the `alpine-s6rc-conf' > tarball) signed with my OpenPGP key. -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227

Re: Using execline in place of shell for s6/s6-rc setup: environment variables?

2VFNsNVE> Attached are their checksums (plus that for the `alpine-s6rc-conf' tarball) signed with my OpenPGP key. On Sat, May 20, 2017 at 12:20:30PM +0800, Casper Ti. Vector wrote: > follow the README in the tarball -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077

Re: execline and $0-based stuff

An example of my attempt, already working on at least 2 Alpine machines: > $ ls -d /etc/s6-rc/main/*getty* > /etc/s6-rc/main/getty.tty1 > $ cat /etc/s6-rc/base/getty/run > #!/bin/rc -e > exec >[2=1] > . /etc/s6-rc/bin/fn.rc > exec `{cdr $self} 38400 $name linux > $ cat /etc/s6-rc/bin/fn.rc >

Re: s6-linux-init, alpine linux, and initramfs

Oh, now I understand what you and Laurent meant: apart from `/proc/cmdline', the kernel also exports its boot parameters (except for `root=...', parameters without a value and possibly something else) into the environment of the init process. This is really useful when not all parameters need to

Re: s6-linux-init, alpine linux, and initramfs

On Tue, Jan 31, 2017 at 09:35:55PM +, Laurent Bercot wrote: > It won't do it in every case: parsing /proc/cmdline is hazardous and > much more difficult than it appears. (There could be quotes, and quoted > spaces, in the elements.) We had a discussion about this on the Alpine > development

Re: s6-rc:

Using the fifo trick [1]? As a side note, though the s6 documentation considers it "dirty", similar methods [2] are widely used for process synchronisation in CSP-style concurrency. [1] . [2]

Re: Some glitches on skarnet.org

Found this just now: : pure C, no python or shell; developed by the OpenBSD people and already included in OpenBSD, which at least makes the code not smell very insecure :) Nevertheless, that client is not mininalistic, which might be a little annoying for

Re: Some glitches on skarnet.org

A shameless plug: might be of some help in understanding the protocol. The script (169 SLOC as of now) is not be directly usable to you since it is written in python, but I tried quite hard to make the workflow as clear and concise as possible :) On Sat,

Some glitches on skarnet.org

* On , `Alternatively, you can checkout a copy of the skalibs "git repository' (yes, the double quote `"' is incorrect). * On the cgit web interface, for example , the code section displays