Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #245721 > unrolled thread

getting a regular user to dump core when a program crashes

Back to article view | Back to linux.debian.user

Contents

  getting a regular user to dump core when a program crashes songbird <songbird@anthive.com> - 2022-02-28 16:10 +0100
    Re: getting a regular user to dump core when a program crashes Greg Wooledge <greg@wooledge.org> - 2022-02-28 16:40 +0100
      Re: getting a regular user to dump core when a program crashes songbird <songbird@anthive.com> - 2022-02-28 17:30 +0100
        Re: getting a regular user to dump core when a program crashes Greg Wooledge <greg@wooledge.org> - 2022-02-28 17:40 +0100
          Re: getting a regular user to dump core when a program crashes The Wanderer <wanderer@fastmail.fm> - 2022-02-28 17:50 +0100
            Re: getting a regular user to dump core when a program crashes songbird <songbird@anthive.com> - 2022-02-28 18:00 +0100
            Re: getting a regular user to dump core when a program crashes Reco <recoverym4n@enotuniq.net> - 2022-02-28 18:20 +0100
            Re: getting a regular user to dump core when a program crashes Greg Wooledge <greg@wooledge.org> - 2022-02-28 18:30 +0100
              Re: getting a regular user to dump core when a program crashes songbird <songbird@anthive.com> - 2022-02-28 19:50 +0100

#245721 — getting a regular user to dump core when a program crashes

i had some fun trying to figure out why a regular user could not
dump a core file and i had all the settings figured out.  since it
was a silly and obvious thing but it stumped me for a bit i 
figured it would be worth sharing.  :)


the answer is at the end...


using Debian testing.


i have my kernel boot line set to:

systemd.dump_core=true


i have these lines in /etc/security/limits.conf:

root            hard    core            unlimited
root            soft    core            unlimited
*               soft    core            unlimited
*               hard    core            unlimited


i have the following set in my /etc/sysctl.conf:

# core file location and file name format
kernel.core_pattern=/crash/core.%u.%E.%p


if i run a program with a known issue (divide by zero) the
core file shows up where it should be if the program is run
by root, but not when a normal user runs it.


what am i missing or what have i screwed up?

root(17)~# ./f
Floating point exception (core dumped)
root(18)~# ls /crash
total 112
-rw------- 1 root root 282624 Feb 28 09:32 'core.0.!root!f.2123'



none of my .bashrc/.profile or etc have anything limited in them
for core file dumps


$ ulimit -a
ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 30998
max locked memory           (kbytes, -l) 1000392
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 30998
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited


turns out it was as simple as the directory permissions on
/crash.

once i set those to allow the proper access then the crashes
would show up.  for some reason i thought that a crashing
program would have systemd or root handling the saving of 
the core file and so a user would not need special access
to where the core file was landing.


$ ls /crash
total 228
-rw------- 1 root root 282624 Feb 28 09:48 'core.0.!root!f.2537'
-rw------- 1 me   me   282624 Feb 28 09:49 'core.1000.!home!me!f.2546'


  songbird

[toc] | [next] | [standalone]

#245722

On Mon, Feb 28, 2022 at 10:01:05AM -0500, songbird wrote:
> 
> i had some fun trying to figure out why a regular user could not
> dump a core file

Just put 'ulimit -c unlimited' into the appropriate dot file to put
things back to how they used to be.

This changed a *really* long time ago.  I don't know exactly when, or
how.  It pissed me off too, but it's the norm now, because everything
has been dumbed down for the common user.

unicorn:~$ grep ulimit .profile 
ulimit -c unlimited		# Argh!  Since when does this default to 0?


For me, .profile is the correct file, because I login on a console and
use startx.  If you login via a GUI DM, some other file will be the
correct one (possibly .xsessionrc but I haven't tested it).

[toc] | [prev] | [next] | [standalone]

#245723

Greg Wooledge wrote:
...
> Just put 'ulimit -c unlimited' into the appropriate dot file to put
> things back to how they used to be.
>
> This changed a *really* long time ago.  I don't know exactly when, or
> how.  It pissed me off too, but it's the norm now, because everything
> has been dumbed down for the common user.
>
> unicorn:~$ grep ulimit .profile 
> ulimit -c unlimited		# Argh!  Since when does this default to 0?
>
>
> For me, .profile is the correct file, because I login on a console and
> use startx.  If you login via a GUI DM, some other file will be the
> correct one (possibly .xsessionrc but I haven't tested it).


did you miss this?

>> me@ant(14)~$ ulimit -a
>> real-time non-blocking time  (microseconds, -R) unlimited
>> core file size              (blocks, -c) unlimited

  i had accomplished the ulimit change already, but the lack of 
the proper permission on the output directory meant that a core
file would not be generated.

  also, i wanted to make sure that all programs running would
be able to dump core upon crashing because i have some kind of
strange lock up going on and i'm not sure what it is coming 
from.  so i want all processes for all users to be able to
be able to be recorded if it happens again.  just trying to 
catch this if i can.  it happens once in a while.  not too 
often.


  songbird

[toc] | [prev] | [next] | [standalone]

#245724

On Mon, Feb 28, 2022 at 11:25:13AM -0500, songbird wrote:
> >> me@ant(14)~$ ulimit -a
> >> real-time non-blocking time  (microseconds, -R) unlimited
> >> core file size              (blocks, -c) unlimited
> 
>   i had accomplished the ulimit change already, but the lack of 
> the proper permission on the output directory meant that a core
> file would not be generated.

What is an "output directory"?  Core files are dumped in the process's
*working* directory, which is "where you are when you run it".  Quite
often that will be $HOME, unless you opened a shell and changed
directory somewhere else, before running a command.  Or unless the
process is invoked by a dot-desktop file that specifies a special
working directory.  Or a systemd unit file is written which specifies
a WorkingDirectory= in it.  And so on.

unicorn:~$ cat coredump.c
main() {
    char *ptr = 0;
    *ptr = 'x';
    return 0;
}
unicorn:~$ gcc -o coredump coredump.c
coredump.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
    1 | main() {
      | ^~~~
unicorn:~$ cd tmp
unicorn:~/tmp$ ../coredump >/var/tmp/outputfile
Segmentation fault (core dumped)
unicorn:~/tmp$ ls -ld core
-rw------- 1 greg greg 249856 Feb 28 11:33 core

Here, the process's binary file lives in /home/greg, its working directory
is /home/greg/tmp, and its stdout has been redirected to a file in
/var/tmp.  The core file goes in /home/greg/tmp, the working directory.

[toc] | [prev] | [next] | [standalone]

#245726

[Multipart message — attachments visible in raw view] — view raw

On 2022-02-28 at 11:35, Greg Wooledge wrote:

> On Mon, Feb 28, 2022 at 11:25:13AM -0500, songbird wrote:
>
>> >> me@ant(14)~$ ulimit -a
>> >> real-time non-blocking time  (microseconds, -R) unlimited
>> >> core file size              (blocks, -c) unlimited
>> 
>>   i had accomplished the ulimit change already, but the lack of 
>> the proper permission on the output directory meant that a core
>> file would not be generated.
> 
> What is an "output directory"?  Core files are dumped in the process's
> *working* directory, which is "where you are when you run it".

By default, yes, that's the case. However, from songbird's original
post:

>>>> i have the following set in my /etc/sysctl.conf:
>>>> 
>>>> # core file location and file name format
>>>> kernel.core_pattern=/crash/core.%u.%E.%p

That appears to be a kernel parameter which defines the path and
filename of the core file.

I imagine that this was set in order to be able to specify a filename
other than the default, with relevant information about the dumping
process (and avoiding the problem of multiple such files overwriting one
another), and that the syntax of the kernel parameter in question is
such that you have to specify the full path to the file.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#245727

The Wanderer wrote:
> On 2022-02-28 at 11:35, Greg Wooledge wrote:
>> On Mon, Feb 28, 2022 at 11:25:13AM -0500, songbird wrote:
>>
>>> >> me@ant(14)~$ ulimit -a
>>> >> real-time non-blocking time  (microseconds, -R) unlimited
>>> >> core file size              (blocks, -c) unlimited
>>>=20
>>>   i had accomplished the ulimit change already, but the lack of=20
>>> the proper permission on the output directory meant that a core
>>> file would not be generated.
>>=20
>> What is an "output directory"?  Core files are dumped in the process's
>> *working* directory, which is "where you are when you run it".
>
> By default, yes, that's the case. However, from songbird's original
> post:
>
>>>>> i have the following set in my /etc/sysctl.conf:
>>>>>=20
>>>>> # core file location and file name format
>>>>> kernel.core_pattern=3D/crash/core.%u.%E.%p
>
> That appears to be a kernel parameter which defines the path and
> filename of the core file.

  yes!  i don't know which process is crashing to cause 
the lockup.  it is nice if all core files from crashes are 
located in one spot so i can find them without having to 
hunt for them.  this may not really work if the process isn't
actually dumping core, but we'll see if i can figure out 
which one it is.


> I imagine that this was set in order to be able to specify a filename
> other than the default, with relevant information about the dumping
> process (and avoiding the problem of multiple such files overwriting one
> another), and that the syntax of the kernel parameter in question is
> such that you have to specify the full path to the file.


  songbird

[toc] | [prev] | [next] | [standalone]

#245728

	Hi.

On Mon, Feb 28, 2022 at 11:41:27AM -0500, The Wanderer wrote:
> On 2022-02-28 at 11:35, Greg Wooledge wrote:
> 
> > On Mon, Feb 28, 2022 at 11:25:13AM -0500, songbird wrote:
> >
> >> >> me@ant(14)~$ ulimit -a
> >> >> real-time non-blocking time  (microseconds, -R) unlimited
> >> >> core file size              (blocks, -c) unlimited
> >> 
> >>   i had accomplished the ulimit change already, but the lack of 
> >> the proper permission on the output directory meant that a core
> >> file would not be generated.
> > 
> > What is an "output directory"?  Core files are dumped in the process's
> > *working* directory, which is "where you are when you run it".
> 
> By default, yes, that's the case. However, from songbird's original
> post:
> 
> >>>> i have the following set in my /etc/sysctl.conf:
> >>>> 
> >>>> # core file location and file name format
> >>>> kernel.core_pattern=/crash/core.%u.%E.%p
> 
> That appears to be a kernel parameter which defines the path and
> filename of the core file.

It can do that too. Quoting the relevant part of the kernel's
documentation (admin-guide/sysctl/kernel.rst.gz) :

If the first character of the pattern is a '|', the kernel will treat
the rest of the pattern as a command to run.  The core dump will be
written to the standard input of that program instead of to a file.


For instance, one can use systemd-coredump (needs a package installed,
though) to write backtraces to journald.
Or, one can specify /dev/null in kernel.core_pattern, thus preventing
core dumps from creating regardless of user's shell limits.


> and that the syntax of the kernel parameter in question is
> such that you have to specify the full path to the file.

When used in such way, it's also prevents user's processes to spam an
entire filesystem with coredumps.

Reco

[toc] | [prev] | [next] | [standalone]

#245729

On Mon, Feb 28, 2022 at 11:41:27AM -0500, The Wanderer wrote:
> By default, yes, that's the case. However, from songbird's original
> post:
> 
> >>>> i have the following set in my /etc/sysctl.conf:
> >>>> 
> >>>> # core file location and file name format
> >>>> kernel.core_pattern=/crash/core.%u.%E.%p
> 
> That appears to be a kernel parameter which defines the path and
> filename of the core file.
> 
> I imagine that this was set in order to be able to specify a filename
> other than the default, with relevant information about the dumping
> process (and avoiding the problem of multiple such files overwriting one
> another), and that the syntax of the kernel parameter in question is
> such that you have to specify the full path to the file.

OK... let's see.  I tried several dead end man pages (why the hell
don't they have comprehensive SEE ALSO sections?!).  Then gave up, then
decided to try "man -k sysctl".  This led me to discover that there is
a sysctl(2) page in addition to sysctl(8) (the latter does NOT link
to the former).

sysctl(2) mentions core_pattern and says to see core(5).

core(5) says:

       By default, a core dump file is  named  core,  but  the  /proc/sys/ker‐
       nel/core_pattern file (since Linux 2.6 and 2.4.21) can be set to define
       a template that is used to name core dump files.  The template can con‐
       tain  % specifiers which are substituted by the following values when a
       core file is created:

No mention is made of specifying *directories* by this mechanism, except
for the %E specifier, which is documented as:

           %E  Pathname of executable, with slashes ('/') replaced by exclama‐
               tion marks ('!') (since Linux 3.0).

Funny how they went out of their way to change slashes to a different
character, isn't it.

But songbird appears to believe that one can put *actual* slashes in this
kernel config file, and have them be treated as an absolute pathname.
Despite this not being mentioned in the man page as far as I could see,
and despite defying all of my experience with core files.

So let's test whether this works.  My testing is occurring on bullseye
running this kernel:

unicorn:~$ uname -r
5.10.0-11-amd64

And here's the test:

unicorn:~$ sudo sh -c 'echo /tmp/core > /proc/sys/kernel/core_pattern'
[sudo] password for greg: 
unicorn:~$ ls -ld core
ls: cannot access 'core': No such file or directory
unicorn:~$ ./coredump
Segmentation fault (core dumped)
unicorn:~$ ls -ld core /tmp/core
ls: cannot access 'core': No such file or directory
-rw------- 1 greg greg 249856 Feb 28 12:16 /tmp/core

Well, that's interesting.  You *can* specify an absolute directory by
this mechanism.  I guess I learned something today.

So, what exactly was the complaint?  That songbird shot themselves in
the foot by specifying an absolute directory for core dumps that wasn't
writable by the user generating the core dumps?  Well, don't do that.

[toc] | [prev] | [next] | [standalone]

#245733

Greg Wooledge wrote:
...
> Well, that's interesting.  You *can* specify an absolute directory by
> this mechanism.  I guess I learned something today.

  :)


> So, what exactly was the complaint?  That songbird shot themselves in
> the foot by specifying an absolute directory for core dumps that wasn't
> writable by the user generating the core dumps?  Well, don't do that.

  um, no, go back and read my initial post.


  songbird

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web