[opensuse] how does a plain user get access to a core dump?
It's been a while since I have reason to, but I need a plain (non-root) user to access his own core dumps, and I've forgotten how that is done? Is there perhaps a way of reverting to having core dumps written to the working dir? -- Per Jessen, Zürich (15.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
20.05.2018 13:36, Per Jessen пишет:
It's been a while since I have reason to, but I need a plain (non-root) user to access his own core dumps, and I've forgotten how that is done?
Is there perhaps a way of reverting to having core dumps written to the working dir?
Just mask /usr/lib/sysctl.d/50-coredump.conf: ln -s /dev/null /etc/syctl.d/50-coredump.conf You may need to re-create initrd. It really became rather pain-point ... yes, file is included by dracut in systemd mode, so you need to rebuild initrd. Alternative is to use file that explicitly resets core_pattern to default which surprisingly is just "core" :) Although "core.%p" is probably more widely used. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
20.05.2018 13:36, Per Jessen пишет:
It's been a while since I have reason to, but I need a plain (non-root) user to access his own core dumps, and I've forgotten how that is done?
Is there perhaps a way of reverting to having core dumps written to the working dir?
Just mask /usr/lib/sysctl.d/50-coredump.conf:
ln -s /dev/null /etc/syctl.d/50-coredump.conf
You may need to re-create initrd. It really became rather pain-point ... yes, file is included by dracut in systemd mode, so you need to rebuild initrd. Alternative is to use file that explicitly resets core_pattern to default which surprisingly is just "core" :) Although "core.%p" is probably more widely used.
Thanks. Yeah, that is what I would use. I don't mind rebuilding the initrd, but adding kernel.core_pattern = core.%p to /etc/sysctl.d/somewhere is easier :-) Looking at the current core_pattern: # cat /proc/sys/kernel/core_pattern |/bin/false I wonder where that comes from? -- Per Jessen, Zürich (16.7°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-20 13:12, Per Jessen wrote:
Andrei Borzenkov wrote:
Thanks. Yeah, that is what I would use. I don't mind rebuilding the initrd, but adding kernel.core_pattern = core.%p to /etc/sysctl.d/somewhere is easier :-)
Looking at the current core_pattern:
# cat /proc/sys/kernel/core_pattern |/bin/false
I wonder where that comes from?
I had notes on that one but I don't remember where. I wonder if systemd-coredump can be modified to change the permissions to the owner of the app that dumped core. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
20.05.2018 14:12, Per Jessen пишет:
Andrei Borzenkov wrote:
20.05.2018 13:36, Per Jessen пишет:
It's been a while since I have reason to, but I need a plain (non-root) user to access his own core dumps, and I've forgotten how that is done?
Is there perhaps a way of reverting to having core dumps written to the working dir?
Just mask /usr/lib/sysctl.d/50-coredump.conf:
ln -s /dev/null /etc/syctl.d/50-coredump.conf
You may need to re-create initrd. It really became rather pain-point ... yes, file is included by dracut in systemd mode, so you need to rebuild initrd. Alternative is to use file that explicitly resets core_pattern to default which surprisingly is just "core" :) Although "core.%p" is probably more widely used.
Thanks. Yeah, that is what I would use. I don't mind rebuilding the initrd, but adding kernel.core_pattern = core.%p to /etc/sysctl.d/somewhere is easier :-)
Looking at the current core_pattern:
# cat /proc/sys/kernel/core_pattern |/bin/false
I wonder where that comes from?
This is explicitly set by systemd on startup with intention that it will be later set by 50-coredump.conf (or whatever). Which means I was wrong - masking this sysctl.d file will leave core dumps disabled instead of leaving them as default. Oh, joy of undocumented ad hoc settings all over systemd code ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
20.05.2018 14:12, Per Jessen пишет:
Andrei Borzenkov wrote:
20.05.2018 13:36, Per Jessen пишет:
It's been a while since I have reason to, but I need a plain (non-root) user to access his own core dumps, and I've forgotten how that is done?
Is there perhaps a way of reverting to having core dumps written to the working dir?
Just mask /usr/lib/sysctl.d/50-coredump.conf:
ln -s /dev/null /etc/syctl.d/50-coredump.conf
You may need to re-create initrd. It really became rather pain-point ... yes, file is included by dracut in systemd mode, so you need to rebuild initrd. Alternative is to use file that explicitly resets core_pattern to default which surprisingly is just "core" :) Although "core.%p" is probably more widely used.
Thanks. Yeah, that is what I would use. I don't mind rebuilding the initrd, but adding kernel.core_pattern = core.%p to /etc/sysctl.d/somewhere is easier :-)
Looking at the current core_pattern:
# cat /proc/sys/kernel/core_pattern |/bin/false
I wonder where that comes from?
This is explicitly set by systemd on startup with intention that it will be later set by 50-coredump.conf (or whatever). Which means I was wrong - masking this sysctl.d file will leave core dumps disabled instead of leaving them as default.
Oh, joy of undocumented ad hoc settings all over systemd code ...
If it's any comfort, I set core-pattern = code.%p - that does exactly what I wanted! The user has access to core dumps right away, no fiddling with coredumpctl and such. Thanks for your help. -- Per Jessen, Zürich (16.7°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-20 21:19, Per Jessen wrote:
Andrei Borzenkov wrote:
If it's any comfort, I set core-pattern = code.%p - that does exactly what I wanted! The user has access to core dumps right away, no fiddling with coredumpctl and such. Thanks for your help.
cer@Telcontar:~> cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e Where %u (numeric) real UID of dumped process So "systemd-coredump" does know the user that owned the process. Maybe patch "systemd-coredump"? -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
So "systemd-coredump" does know the user that owned the process. Maybe patch "systemd-coredump"?
ISTR that it did 'the right thing' (i.e., set proper permissions) on my TW system last time I needed it (but by default I have turned them off). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-21 11:03, Peter Suetterlin wrote:
Carlos E. R. wrote:
So "systemd-coredump" does know the user that owned the process. Maybe patch "systemd-coredump"?
ISTR that it did 'the right thing' (i.e., set proper permissions) on my TW system last time I needed it (but by default I have turned them off).
You mean that in TW you can have coredumps stored in var/lib/systemd/coredump/ have ownership set to the user that owned the process that crashed, instead as Leap does now, sets them owned by root only? -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2018-05-20 21:19, Per Jessen wrote:
Andrei Borzenkov wrote:
If it's any comfort, I set core-pattern = code.%p - that does exactly what I wanted! The user has access to core dumps right away, no fiddling with coredumpctl and such. Thanks for your help.
cer@Telcontar:~> cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e
Ye, I saw something like that suggested, but that leaves a user to have to fiddle with coredumpctl, which afaict requires he is in group 'systemd-journal'. Setting core-pattern = code.%p does exactly what a user needs, without too much fuss. -- Per Jessen, Zürich (22.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-21 16:14, Per Jessen wrote:
Carlos E. R. wrote:
On 2018-05-20 21:19, Per Jessen wrote:
Andrei Borzenkov wrote:
If it's any comfort, I set core-pattern = code.%p - that does exactly what I wanted! The user has access to core dumps right away, no fiddling with coredumpctl and such. Thanks for your help.
cer@Telcontar:~> cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e
Ye, I saw something like that suggested, but that leaves a user to have to fiddle with coredumpctl, which afaict requires he is in group 'systemd-journal'. Setting core-pattern = code.%p does exactly what a user needs, without too much fuss.
No, the user doesn't need to fiddle. Just access the directory where the dumps are stored, but currently he doesn't get permission. The thing is, if now other apps dump core, you will have to go find them all over the disk. For instance, on my media center/server there are two apps that crash frequently, and which run full time. One of them is on automatic restart, and can crash a dozen times in succession and dump core each time. With the default systemd handling, I know that the cores will be deleted in a week, automatically. I don't need to care much about it. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 05/21/2018 02:53 PM, Carlos E. R. wrote:
No, the user doesn't need to fiddle. Just access the directory where the dumps are stored, but currently he doesn't get permission.
Perhaps I'm missing something, but I thought giving mere mortals access to core dumps etc. was a security risk. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-21 21:17, James Knott wrote:
On 05/21/2018 02:53 PM, Carlos E. R. wrote:
No, the user doesn't need to fiddle. Just access the directory where the dumps are stored, but currently he doesn't get permission.
Perhaps I'm missing something, but I thought giving mere mortals access to core dumps etc. was a security risk.
Not if it is your program which crashed. A developer needs access to his own crashes to debug them. A user may want to mail his crash data to a developer somewhere else. It is not giving the user access to coredumps of everybody, but only to his own coredumps. If you disable systemd intervention, and leave things as they were some years ago, the coredumps are left on the directory of the user and owned by the user. This has been so for decades, so not a security risk, IMHO. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
If you disable systemd intervention,
With Leap15, it is disabled by default. No core dumps. -- Per Jessen, Zürich (14.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, May 22, 2018 at 9:05 AM, Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
If you disable systemd intervention,
With Leap15, it is disabled by default. No core dumps.
You need to install systemd-coredump package to get standard systemd handling back. Probably should be in release notes. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Tue, May 22, 2018 at 9:05 AM, Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
If you disable systemd intervention,
With Leap15, it is disabled by default. No core dumps.
You need to install systemd-coredump package to get standard systemd handling back. Probably should be in release notes.
Aha - just for anyone else reading this, I'm running the minimal server pattern. -- Per Jessen, Zürich (17.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 05/21/2018 02:53 PM, Carlos E. R. wrote:
No, the user doesn't need to fiddle. Just access the directory where the dumps are stored, but currently he doesn't get permission.
Perhaps I'm missing something, but I thought giving mere mortals access to core dumps etc. was a security risk.
If you're writing something and it core dumps, how would you debug it without being able to read the dump? -- Per Jessen, Zürich (14.3°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2018-05-21 16:14, Per Jessen wrote:
Carlos E. R. wrote:
On 2018-05-20 21:19, Per Jessen wrote:
Andrei Borzenkov wrote:
If it's any comfort, I set core-pattern = code.%p - that does exactly what I wanted! The user has access to core dumps right away, no fiddling with coredumpctl and such. Thanks for your help.
cer@Telcontar:~> cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e
Ye, I saw something like that suggested, but that leaves a user to have to fiddle with coredumpctl, which afaict requires he is in group 'systemd-journal'. Setting core-pattern = code.%p does exactly what a user needs, without too much fuss.
No, the user doesn't need to fiddle. Just access the directory where the dumps are stored, but currently he doesn't get permission.
I thought that is working as designed. When I googled, I came across this page: https://www.suse.com/de-de/support/kb/doc/?id=7017137 A quick browse suggest coredumpctl is used to access core dumps.
The thing is, if now other apps dump core, you will have to go find them all over the disk.
I guess it might depend on the environment, but we don't have enough for that to be a real problem :-) -- Per Jessen, Zürich (14.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-22 08:02, Per Jessen wrote:
Carlos E. R. wrote:
No, the user doesn't need to fiddle. Just access the directory where the dumps are stored, but currently he doesn't get permission.
I thought that is working as designed. When I googled, I came across this page:
It says that it is file "/etc/sysctl.d/50-coredump.conf" which creates the pipe in "/proc/sys/kernel/core_pattern", but that conf file does not exist in my system. There is, however, "/usr/lib/sysctl.d/50-coredump.conf"
A quick browse suggest coredumpctl is used to access core dumps.
Now, that is very interesting! "coredumpctl list" prints the list of coredumps. For instance, I get (452 entries): ... Tue 2018-05-15 16:20:18 CEST 11484 1000 100 11 /usr/lib/tracker-store Tue 2018-05-15 21:29:37 CEST 30545 1000 100 11 /home/cer/MovistarTV.Server.2.0.13-alpha-indep/Kodi_MovistarTV_Server.pvr Wed 2018-05-16 17:28:27 CEST 24928 1000 100 11 /usr/lib/tracker-store Thu 2018-05-17 13:48:00 CEST 6122 1000 100 11 /usr/lib/tracker-store Fri 2018-05-18 16:04:23 CEST 18341 1000 100 11 /usr/lib/tracker-store Sat 2018-05-19 13:00:02 CEST 31511 1000 100 11 * /usr/lib/tracker-store Sun 2018-05-20 13:38:05 CEST 12251 1000 100 11 * /usr/lib/tracker-store Sun 2018-05-20 22:59:02 CEST 30036 1000 100 11 * /usr/lib64/kodi/kodi.bin Mon 2018-05-21 13:38:26 CEST 26768 1000 100 11 * /home/cer/MovistarTV.Server.2.0.13-alpha-indep/Kodi_MovistarTV_Server.pvr Mon 2018-05-21 18:17:08 CEST 25411 1000 100 11 * /usr/lib/tracker-store So I try to obtain one or two, but the file is empty: cer@Isengard:~> coredumpctl -o kodi.core dump /usr/lib64/kodi/kodi.bin PID: 30036 (kodi.bin) UID: 1000 (cer) GID: 100 (users) Signal: 11 (SEGV) Timestamp: Sun 2018-05-20 22:58:11 CEST (1 day 14h ago) Command Line: /usr/lib64/kodi/kodi.bin Executable: /usr/lib64/kodi/kodi.bin Control Group: / Slice: -.slice Boot ID: 499842fc44574e29abc11e0d2eb4ac27 Machine ID: af5da4da5956dc08183725bc583a0cd5 Hostname: Isengard Coredump: /var/lib/systemd/coredump/core.kodi\x2ebin.1000.499842fc44574e29abc11e0d2eb4ac27.30036.1526849891000000 Message: Process 30036 (kodi.bin) of user 1000 dumped core. More than one entry matches, ignoring rest. cer@Isengard:~> man coredumpctl cer@Isengard:~> l kodi.core -rw-r--r-- 1 cer users 0 May 22 13:32 kodi.core cer@Isengard:~> I try specifying the PID, per the man page: cer@Isengard:~> coredumpctl -o kodi.core dump 30036 /usr/lib64/kodi/kodi.bin PID: 30036 (kodi.bin) UID: 1000 (cer) GID: 100 (users) Signal: 11 (SEGV) Timestamp: Sun 2018-05-20 22:58:11 CEST (1 day 14h ago) Command Line: /usr/lib64/kodi/kodi.bin Executable: /usr/lib64/kodi/kodi.bin Control Group: / Slice: -.slice Boot ID: 499842fc44574e29abc11e0d2eb4ac27 Machine ID: af5da4da5956dc08183725bc583a0cd5 Hostname: Isengard Coredump: /var/lib/systemd/coredump/core.kodi\x2ebin.1000.499842fc44574e29abc11e0d2eb4ac27.30036.1526849891000000 Message: Process 30036 (kodi.bin) of user 1000 dumped core. More than one entry matches, ignoring rest. cer@Isengard:~> l kodi.core -rw-r--r-- 1 cer users 0 May 22 13:38 kodi.core cer@Isengard:~> or cer@Isengard:~> coredumpctl -o kodi.core dump 30036 PID: 30036 (kodi.bin) UID: 1000 (cer) GID: 100 (users) Signal: 11 (SEGV) Timestamp: Sun 2018-05-20 22:58:11 CEST (1 day 14h ago) Command Line: /usr/lib64/kodi/kodi.bin Executable: /usr/lib64/kodi/kodi.bin Control Group: / Slice: -.slice Boot ID: 499842fc44574e29abc11e0d2eb4ac27 Machine ID: af5da4da5956dc08183725bc583a0cd5 Hostname: Isengard Coredump: /var/lib/systemd/coredump/core.kodi\x2ebin.1000.499842fc44574e29abc11e0d2eb4ac27.30036.1526849891000000 Message: Process 30036 (kodi.bin) of user 1000 dumped core. More than one entry matches, ignoring rest. cer@Isengard:~> l kodi.core -rw-r--r-- 1 cer users 0 May 22 13:41 kodi.core cer@Isengard:~> Although there is only one hit for that PID: cer@Isengard:~> coredumpctl list | grep 30036 Sun 2018-05-20 22:59:02 CEST 30036 1000 100 11 * /usr/lib64/kodi/kodi.bin cer@Isengard:~> The core file exists: cer@Isengard:~> l /var/lib/systemd/coredump/core.kodi\\x2ebin.1000.499842fc44574e29abc11e0d2eb4ac27.30036.1526849891000000 -rw-r-----+ 1 root root 1073741824 May 20 22:58 /var/lib/systemd/coredump/core.kodi\x2ebin.1000.499842fc44574e29abc11e0d2eb4ac27.30036.1526849891000000 cer@Isengard:~> Same result as root. Is this a bug?
The thing is, if now other apps dump core, you will have to go find them all over the disk.
I guess it might depend on the environment, but we don't have enough for that to be a real problem :-)
cer@Isengard:~> coredumpctl list | wc -l 452 cer@Isengard:~> My disk would be full by now :-o -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
cer@Isengard:~> coredumpctl list | wc -l 452 cer@Isengard:~>
My disk would be full by now :-o
Different situation - you want to limit the space taken up by core dumps, I want plain users to be able to read their own core dumps, with a minimum of fuss. -- Per Jessen, Zürich (21.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-22 14:03, Per Jessen wrote:
Carlos E. R. wrote:
cer@Isengard:~> coredumpctl list | wc -l 452 cer@Isengard:~>
My disk would be full by now :-o
Different situation - you want to limit the space taken up by core dumps, I want plain users to be able to read their own core dumps, with a minimum of fuss.
Apparently, "coredumpctl" would give that access, but it fails to work. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
22.05.2018 15:09, Carlos E. R. пишет:
On 2018-05-22 14:03, Per Jessen wrote:
Carlos E. R. wrote:
cer@Isengard:~> coredumpctl list | wc -l 452 cer@Isengard:~>
My disk would be full by now :-o
Different situation - you want to limit the space taken up by core dumps, I want plain users to be able to read their own core dumps, with a minimum of fuss.
Apparently, "coredumpctl" would give that access, but it fails to work.
I briefly tested it and it worked both on Leap 42.3 and TW for trivial test case. May be core file gets corrupted (e.g. it would exceed limit so only partial file was written).
On 2018-05-22 20:03, Andrei Borzenkov wrote:
22.05.2018 15:09, Carlos E. R. пишет:
On 2018-05-22 14:03, Per Jessen wrote:
Carlos E. R. wrote:
cer@Isengard:~> coredumpctl list | wc -l 452 cer@Isengard:~>
My disk would be full by now :-o
Different situation - you want to limit the space taken up by core dumps, I want plain users to be able to read their own core dumps, with a minimum of fuss.
Apparently, "coredumpctl" would give that access, but it fails to work.
I briefly tested it and it worked both on Leap 42.3 and TW for trivial test case. May be core file gets corrupted (e.g. it would exceed limit so only partial file was written).
How can I find out if that is the case? -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
22.05.2018 21:25, Carlos E. R. пишет:
On 2018-05-22 20:03, Andrei Borzenkov wrote:
22.05.2018 15:09, Carlos E. R. пишет:
On 2018-05-22 14:03, Per Jessen wrote:
Carlos E. R. wrote:
cer@Isengard:~> coredumpctl list | wc -l 452 cer@Isengard:~>
My disk would be full by now :-o
Different situation - you want to limit the space taken up by core dumps, I want plain users to be able to read their own core dumps, with a minimum of fuss.
Apparently, "coredumpctl" would give that access, but it fails to work.
I briefly tested it and it worked both on Leap 42.3 and TW for trivial test case. May be core file gets corrupted (e.g. it would exceed limit so only partial file was written).
How can I find out if that is the case?
You can try to read logs if there are anything of interest. You can try to use gdb with this file to see if it complains. You can try increase coredumpctl verbosity by setting SYSTEMD_LOG_LEVEL=debug before calling it. File size is exactly 1GiB which is rather suspicious. "readelf -a corefile" displays various sections which may give hint whether they are beyond 1GiB.
On 2018-05-22 21:02, Andrei Borzenkov wrote:
22.05.2018 21:25, Carlos E. R. пишет:
On 2018-05-22 20:03, Andrei Borzenkov wrote:
22.05.2018 15:09, Carlos E. R. пишет:
On 2018-05-22 14:03, Per Jessen wrote:
Carlos E. R. wrote:
cer@Isengard:~> coredumpctl list | wc -l 452 cer@Isengard:~>
My disk would be full by now :-o
Different situation - you want to limit the space taken up by core dumps, I want plain users to be able to read their own core dumps, with a minimum of fuss.
Apparently, "coredumpctl" would give that access, but it fails to work.
I briefly tested it and it worked both on Leap 42.3 and TW for trivial test case. May be core file gets corrupted (e.g. it would exceed limit so only partial file was written).
How can I find out if that is the case?
You can try to read logs if there are anything of interest. You can try to use gdb with this file to see if it complains. You can try increase coredumpctl verbosity by setting SYSTEMD_LOG_LEVEL=debug before calling it.
It says a lot, but nothing I understand: Isengard:~ # SYSTEMD_LOG_LEVEL=debug coredumpctl -o kodi.core dump 30036 Adding pattern: COREDUMP_PID=30036 Root directory /var/log/journal added. Considering /var/log/journal/af5da4da5956dc08183725bc583a0cd5. Directory /var/log/journal/af5da4da5956dc08183725bc583a0cd5 added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@3c2c249ef07f42e8ba09b71858f9f47a-0000000000000001-00056466e78cdbf1.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1011.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-0000000000291324-00055d003fd5196f.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@00056bd7342baee5-9ea888dafaf66c61.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-000000000024d048-00055a5ff77890e9.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-000000000023126a-000559545fb86000.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-0000000000385fdb-000569d7c02fb974.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-00000000002acc04-00055e08fe3c833c.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-0000000000318614-0005629dae8ca77c.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-00000000002ad7b9-00055e102dc7f11e.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@23f7180cd6ac408db140aa8db509cd15-0000000000000001-00056a6dc6ea879a.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@000564668c3b7e01-e44cf80ac5bd5330.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@000567c2b68f21c9-aad424ad9e74e8e3.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-0000000000231e08-0005595b8d7f72ce.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-00000000001f9dde-0005573150f88d09.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@a8d3b2606dd144bcbedf96c5221e83b8-0000000000000001-000567e247c28cfb.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-00000000002fd47c-000561822c599977.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@000567c291af8859-46e232083b4e146d.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1011@d57b423abf7a4c3ab631895c316a8124-000000000031861f-0005629daef3a9aa.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-00000000002c8932-00055f1d98b3496c.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@00056466cbfe0b7c-4765d4a1fe373fb0.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@0005646698d1b055-942143d8c3a3c1a6.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@00056a6dc7197dc5-e451a42da8891daa.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@a8d3b2606dd144bcbedf96c5221e83b8-0000000000368a27-000568a51437caa6.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-0000000000291313-00055d003f520497.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@00056466e7b991fd-16f750787e38ec77.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-0000000000215b90-0005584db1751e90.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@0005646695b36c73-2e150e39d0cac09e.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@0005646667079247-63a12d66ea4fd481.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-00000000003185ef-0005629da311e75c.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1100.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-00000000002c89e1-00055f1e09b131e8.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-000000000026f290-00055bbf7b1321f2.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-000000000033452f-000563c65eb8e93f.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-000000000026868b-00055b7cbdf01e5e.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-000000000034b6da-00056635b446c2d3.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-00000000002fda7e-00056185f2f5e229.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@000567e247efd1f1-c31b201235f2f590.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1011@d57b423abf7a4c3ab631895c316a8124-000000000029131e-00055d003fd50e45.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-0000000000368a26-000568a513b5091b.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-00000000002e323e-00056062483d474a.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@000564666e2191be-566a29d73c964a6d.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/user-1000@ece5efb3c80d4e9f8adeef9654fe93d2-0000000000291f1d-00055d078d81efe7.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-000000000024cdd5-00055a5e7fd847f3.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@00056b224721a4df-0f851c4e2b326c05.journal~ added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-0000000000215684-0005584a992c9ca0.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-0000000000283c3b-00055c7bf860ac92.journal added. File /var/log/journal/af5da4da5956dc08183725bc583a0cd5/system@8b0e6d2f7ff34e02bc0463a60515221c-00000000002e280e-00056057e8d926e3.journal added. Journal filter: (MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 AND COREDUMP_PID=30036) PID: 30036 (kodi.bin) UID: 1000 (cer) GID: 100 (users) Signal: 11 (SEGV) Timestamp: Sun 2018-05-20 22:58:11 CEST (1 day 22h ago) Command Line: /usr/lib64/kodi/kodi.bin Executable: /usr/lib64/kodi/kodi.bin Control Group: / Slice: -.slice Boot ID: 499842fc44574e29abc11e0d2eb4ac27 Machine ID: af5da4da5956dc08183725bc583a0cd5 Hostname: Isengard Coredump: /var/lib/systemd/coredump/core.kodi\x2ebin.1000.499842fc44574e29abc11e0d2eb4ac27.30036.1526849891000000 Message: Process 30036 (kodi.bin) of user 1000 dumped core. More than one entry matches, ignoring rest. Directory /var/log/journal/af5da4da5956dc08183725bc583a0cd5 removed. Root directory /var/log/journal removed. mmap cache statistics: 640 hit, 56 miss Isengard:~ # l kodi.core -rw-r--r-- 1 root root 0 May 22 21:53 kodi.core Isengard:~ #
File size is exactly 1GiB which is rather suspicious. "readelf -a corefile" displays various sections which may give hint whether they are beyond 1GiB.
I have other coredumps much smaller, same problem: Isengard:~ # ls -lh /var/lib/systemd/coredump/ total 2.4G -rw-r-----+ 1 root root 80K May 21 13:38 core.Kodi_MovistarTV.1000.499842fc44574e29abc11e0d2eb4ac27.26768.1526902706000000 -rw-r-----+ 1 root root 1.0G May 22 21:15 core.kodi\x2ebin.1000.499842fc44574e29abc11e0d2eb4ac27.27841.1527016529000000 -rw-r-----+ 1 root root 1.0G May 20 22:58 core.kodi\x2ebin.1000.499842fc44574e29abc11e0d2eb4ac27.30036.1526849891000000 -rw-r-----+ 1 root root 88M May 20 13:38 core.tracker-store.1000.499842fc44574e29abc11e0d2eb4ac27.12251.1526816284000000 -rw-r-----+ 1 root root 90M May 21 18:17 core.tracker-store.1000.499842fc44574e29abc11e0d2eb4ac27.25411.1526919428000000 -rw-r-----+ 1 root root 84M May 19 13:00 core.tracker-store.1000.499842fc44574e29abc11e0d2eb4ac27.31511.1526727602000000 -rw-r-----+ 1 root root 88M May 22 15:48 core.tracker-store.1000.499842fc44574e29abc11e0d2eb4ac27.6206.1526996899000000 Isengard:~ # Isengard:~ # coredumpctl -o tracker.core dump 25411 PID: 25411 (tracker-store) UID: 1000 (cer) GID: 100 (users) Signal: 11 (SEGV) Timestamp: Mon 2018-05-21 18:17:08 CEST (1 day 3h ago) Command Line: /usr/lib/tracker-store Executable: /usr/lib/tracker-store Control Group: / Slice: -.slice Boot ID: 499842fc44574e29abc11e0d2eb4ac27 Machine ID: af5da4da5956dc08183725bc583a0cd5 Hostname: Isengard Coredump: /var/lib/systemd/coredump/core.tracker-store.1000.499842fc44574e29abc11e0d2eb4ac27.25411.1526919428000000 Message: Process 25411 (tracker-store) of user 1000 dumped core. More than one entry matches, ignoring rest. Isengard:~ # l tracker.core -rw-r--r-- 1 root root 0 May 22 22:02 tracker.core Isengard:~ # readelf -a /var/lib/systemd/coredump/core.Kodi_MovistarTV.1000.499842fc44574e29abc11e0d2eb4ac27.26768.1526902706000000 | less Is too big, using susepaste: <http://paste.opensuse.org/92177671> Says nothing to me, sorry. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
20.05.2018 22:13, Andrei Borzenkov пишет: ...
20.05.2018 13:36, Per Jessen пишет:
Looking at the current core_pattern:
# cat /proc/sys/kernel/core_pattern |/bin/false
I wonder where that comes from?
This is explicitly set by systemd on startup with intention that it will be later set by 50-coredump.conf (or whatever). Which means I was wrong - masking this sysctl.d file will leave core dumps disabled instead of leaving them as default.
Hmm ... this was introduced in systemd v229 and Leap 42.3 is on v228 (and masking shipped sysctl conf file does restore default). Are you on TW or Leap 15? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
20.05.2018 22:13, Andrei Borzenkov пишет: ...
20.05.2018 13:36, Per Jessen пишет:
Looking at the current core_pattern:
# cat /proc/sys/kernel/core_pattern |/bin/false
I wonder where that comes from?
This is explicitly set by systemd on startup with intention that it will be later set by 50-coredump.conf (or whatever). Which means I was wrong - masking this sysctl.d file will leave core dumps disabled instead of leaving them as default.
Hmm ... this was introduced in systemd v229 and Leap 42.3 is on v228 (and masking shipped sysctl conf file does restore default). Are you on TW or Leap 15?
Yeah, leap15. -- Per Jessen, Zürich (15.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Andrei Borzenkov -
Carlos E. R. -
James Knott -
Per Jessen -
Peter Suetterlin