Re: Core dump of crashing service program
I am replying to this after the fact to clarify things. On Tue, Aug 9, 2022 at 12:16 PM Laurent Bercot wrote: > In order to change this default, you need to modify stage 1. This > is dangerous, so pay attention to typos. > After running s6-linux-init-maker and installing the result, edit > your /etc/s6-linux-init/current/bin/init file. Normally this file > is an execline script consisting of just one call to s6-linux-init > with some options. > So, on my system the one-liner script that launches s6-linux-init ends up being /sbin/s6-init. This I presume is the result of choices made by Artix packaging (e.g., /etc/s6/current instead of /etc/s6-linux-init/current). Anyhoo, the script /sbin/init after the mods contains: #!/usr/bin/execlineb -S0 s6-softlimit -c= -- s6-linux-init -c "/etc/s6/current" -m 0022 -p "/usr/bin:/bin" -- "$@" The system boots normally and I have verified that s6-svscan (PID 1) has unlimited core size.
Re: Core dump of crashing service program
> In order to change this default, you need to modify stage 1.
after that all child processes will use these settings as default.
> After that, if your services still cannot create coredumps, then it
> means the kernel sets the hard limit at 0, and that will be more
> difficult to work around. (Might be time to give an option back to
> s6-softlimit so it can modify hard limits as well...)
what about making /sbin/init a shell script that execs into s6-l-i?
e. g. /sbin/init (symlink to /sbin/s6-init.sh):
#!/bin/mksh
trap : SIGINT SIGQUIT
umask 0022
ulimit -Sc 0 # set soft limit for coredumpsize here
cd /
PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/busybox:/toybox"
export PATH
hostname darkstar # set default hostname, can be changed later
exec s6-setsid -sI /bin/s6-linux-init -c "/etc/s6-linux-init/current" -m 0022 \
-p "$PATH" -s "/run/initenv" -- ${1+"$@"}
now you can set both limits (soft and hard) in the right place
via ulimit -S -c (soft) and ulimit -H -c (hard) using the shell's "ulimit"
builtin.
Re: Core dump of crashing service program
> * https://wiki.artixlinux.org/Main/LocalUserServicesOns6 More specifically, this: * https://wiki.artixlinux.org/Main/LocalUserServicesOns6#Complete_s6_supervision_.28optional.29
Re: Core dump of crashing service program
El mar, 9 ago 2022 a las 9:27, Liviu Nicoara escribió: > >> Your earlier posts do not mention s6-rc, though, only s6, so I'm not >> sure if the system that you are dealing with is using it. > > Yep, s6 and s6-rc (artix w/ s6). Will do my own homework. Oh, Artix. They have official support for s6 + s6-rc + s6-linux-init, and the documentation you need. Read this: * https://wiki.artixlinux.org/Main/S6#Updating_bundle_contents * https://wiki.artixlinux.org/Main/LocalUserServicesOns6 TL;DR: look at Artix' /etc/s6/adminsv directory and 's6-db-reload' script. G.
Re: Core dump of crashing service program
On Tue, Aug 9, 2022 at 12:16 PM Laurent Bercot wrote: > > >... Yes, > >my system uses s6-linux-init and I am using s6-rc as a service manager. > >... > With s6-l-i, since the supervision tree is started very early, and > s6-svscan is pid 1, all the services are started with the default > resource limits set by the kernel. ... > > In order to change this default, you need to modify stage 1. ... > Then reboot. > Outstanding. I am going to link this to a posting I made on Artix s6 forum board about the same topic. > > After that, if your services still cannot create coredumps, then it > means the kernel sets the hard limit at 0, and that will be more > difficult to work around. (Might be time to give an option back to > s6-softlimit so it can modify hard limits as well...) > Hard limit is unlimited, AFAICT.
Re: Core dump of crashing service program
I converted all my arch boxes to artix a while ago, and I opted for s6 after reading the "why another supervision suite" page. All is peachy and I never used a display manager (starting my graphical window manager from the console) until I decided to start using ly, which has no s6 support. Yes, my system uses s6-linux-init and I am using s6-rc as a service manager. Okay, cool. Well, your post makes me realize there is something missing in s6-l-i: it handles the environment of the supervision tree, as in environment variables, but not the other parts of a process's state, such as resource limits. Sorry about that! It has actually never come up before. With s6-l-i, since the supervision tree is started very early, and s6-svscan is pid 1, all the services are started with the default resource limits set by the kernel. So if the default for the core size is 0, no supervised service will be able to create a core. (This is generally a good thing, but it should ideally be configurable.) In order to change this default, you need to modify stage 1. This is dangerous, so pay attention to typos. After running s6-linux-init-maker and installing the result, edit your /etc/s6-linux-init/current/bin/init file. Normally this file is an execline script consisting of just one call to s6-linux-init with some options. Add the following line *before* the s6-linux-init line: s6-softlimit -c= -- (You can use the full path to s6-softlimit, but if it's /usr/bin or /bin it should not matter.) Then reboot. After that, if your services still cannot create coredumps, then it means the kernel sets the hard limit at 0, and that will be more difficult to work around. (Might be time to give an option back to s6-softlimit so it can modify hard limits as well...) -- Laurent
Re: Core dump of crashing service program
Liviu Nicoara writes: It's actually pretty cool. It is a oneshot service that runs all sysctl settings in /etc/sysctl.d. System is artix. Ah okay. i'm on Gentoo, using OpenRC (but still hoping to move to using s6 eventually, as i used to do on Void, once i find enough tuits ...), and there's a 'sysctl' service run by in the 'boot' runlevel. Quite the opposite, I want coredumps, esp. those originating in crashing services (e.g., the display manager I am tinkering with, launched via a service). Oh, yes, sorry, i misread your earlier post. Well, as far as i can tell, on my system the default ulimit is specified via /etc/login.defs; i presume the fact that the line #ULIMIT 2097152 is commented out is what results in my system's default ulimit being 'unlimited'. Alexis.
Re: Core dump of crashing service program
On Tue, Aug 9, 2022 at 4:51 AM Laurent Bercot wrote: > > > > Well, to answer your questions, we'd have to know more details about > your setup and what exactly you are doing. > > Are you using a distribution? Which one? How are you launching the > s6 supervision tree: is it the first thing when you boot (i.e. you're > using s6-linux-init)? Is it a part of your standard distribution boot > sequence, in which case you likely already have a service manager? > What role do you want s6 to play here? > I converted all my arch boxes to artix a while ago, and I opted for s6 after reading the "why another supervision suite" page. All is peachy and I never used a display manager (starting my graphical window manager from the console) until I decided to start using ly, which has no s6 support. Yes, my system uses s6-linux-init and I am using s6-rc as a service manager. I am currently reading and trying to understand the differences between runlevels and what services should run in one vs the other and trying to figure out what to bundle in my default in order to get to use this particular display manager.
Re: Core dump of crashing service program
On Mon, Aug 8, 2022 at 10:51 PM Guillermo wrote: > G:El lun, 8 ago 2022 a las 16:23, Liviu Nicoara escribió: > > > > You bundle the s6-rc atomic services.that you want up when you enter > (an equivalent of) runlevel 5. If when you say "runlevel 5" you are > thinking of Debian or something like it, those would be, more or less, > s6-rc versions of all /etc/rcS.d/S* and /etc/rc5.d/S* services, if I > remember the details of Debian's (non-systemd) init system correctly. > Ok, that is a good starting point for me. > > Your earlier posts do not mention s6-rc, though, only s6, so I'm not > sure if the system that you are dealing with is using it. > Yep, s6 and s6-rc (artix w/ s6). Will do my own homework.
Re: Core dump of crashing service program
On Mon, Aug 8, 2022 at 8:09 PM Alexis wrote: > > Liviu Nicoara writes: > > > ... > > i'm not sure why there's a sysctl service on your system, but > initial kernel parameters such as kernel.core_pattern should be > able to be set via the sysctl.conf file, as well as (at least for > Linux kernels) via the kernel command line. > It's actually pretty cool. It is a oneshot service that runs all sysctl settings in /etc/sysctl.d. System is artix. > Regarding your particular situation, if the reason you're wanting > a core size of 0 is to avoid core dumps getting created, you could > try specifying /dev/null as the file for kernel.core_pattern: > Quite the opposite, I want coredumps, esp. those originating in crashing services (e.g., the display manager I am tinkering with, launched via a service). Thanks.
Re: Core dump of crashing service program
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. Well, to answer your questions, we'd have to know more details about your setup and what exactly you are doing. Are you using a distribution? Which one? How are you launching the s6 supervision tree: is it the first thing when you boot (i.e. you're using s6-linux-init)? Is it a part of your standard distribution boot sequence, in which case you likely already have a service manager? What role do you want s6 to play here? -- Laurent
Re: Core dump of crashing service program
G:El lun, 8 ago 2022 a las 16:23, Liviu Nicoara escribió: > > 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? You bundle the s6-rc atomic services.that you want up when you enter (an equivalent of) runlevel 5. If when you say "runlevel 5" you are thinking of Debian or something like it, those would be, more or less, s6-rc versions of all /etc/rcS.d/S* and /etc/rc5.d/S* services, if I remember the details of Debian's (non-systemd) init system correctly. Your earlier posts do not mention s6-rc, though, only s6, so I'm not sure if the system that you are dealing with is using it. G.
Re: Core dump of crashing service program
Liviu Nicoara writes: 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'm not sure why there's a sysctl service on your system, but initial kernel parameters such as kernel.core_pattern should be able to be set via the sysctl.conf file, as well as (at least for Linux kernels) via the kernel command line. Regarding your particular situation, if the reason you're wanting a core size of 0 is to avoid core dumps getting created, you could try specifying /dev/null as the file for kernel.core_pattern: kernel.core_pattern=/dev/null Alexis.
Re: Core dump of crashing service program
> > - 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
Re: Core dump of crashing service program
Hi, I am working on a service and a part of this work is investigating a crash that occurs only when the service program is launched via exec from the service run script. My initial thought was to inspect the coredump but none is created although I have verified that both my user and root can create coredumps. Are coredumps ever created from crashing services under s6? I have a feeling that I am missing some s6 paradigm here. Thanks for any help. - By default, s6 services are started with their cwd set in the service directory. Check there, you may have a coredump. - 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). Good luck, -- Laurent
