>
> - By default, s6 services are started with their cwd set in the
> service directory. Check there, you may have a coredump.
>
I managed to figure that one out. No dumps there. But ...
>
> - Depending on how and when you start the supervision tree, the run
> scripts may not be inheriting the core dump settings that you have when
> you log in. A supervision tree will inherit boot time settings, which
> may or may not have been modified yet in the boot sequence depending on
> when you start s6-svscan, and all the services will start with the
> environment they inherit from s6-svscan. Check your boot scripts for
> the place where your core dump parameters are set (typically a sysctl
> invocation).
>
I continue to be confused about how to enable the core ulimit upon boot,
before s6-svscan starts. AFAICT, the sysctl service (which starts after
s6-svscan) can configure only one parameter, core_pattern, with which I can
only set a location. That is good but not enough. The needed ulimit
invocation wherever I put it comes in later by which time s6-svscan is
already launched with a core size of 0. So, I used a bigger hammer by
altering the s6-supervise process' core ulimit and that gave me the core,
found the bug, etc. Yaay.
I am in over my head. I know next to zero about runlevels and the
initialization orchestra. What is the correct way to get s6 to give me
something that looks like runlevel 5 (a graphical display manager)? From my
reading, is via bundles and I get the concept, but what is it that I
should bundle? Please ignore the question if it's out of place.
Thx
Received on Mon Aug 08 2022 - 21:23:07 CEST