On 2016-12-01 14:14, Patrick Shanahan wrote:

* Per Jessen [12-01-16 04:08]:

...

Judging by /proc/sys/kernel/core_pattern, it looks like systemd is now somehow dealing with MY core dump?

# cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

It appears to end up in /var/lib/systemd/coredump, where I can read the files, but I cannot delete them? Seems like everybody else can read it - that's surely not right?

This appears to be new in Leap422 - in Leap421, we had just 'core':

# cat /proc/sys/kernel/core_pattern core

appears same in Tw: 08:11 Crash:~ > cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

and ends in /var/lib/systemd/coredump/ but as root I can delete them

But not as the user of the application that dumped core. If you are a developer working in some software that dumps core, you can not analyze your own software problem. It can be read by root, and users in the root group. It is easier for the administrator to collect them, delete or send to the developers "outside", but not for the users to do anything. If there is some control about the permissions of cores, it would be better they belonged to a "coredump" group, and make affected users to belong there. Or leave the original permissions, core belongs to the user causing it. I have no idea if/how that is possible. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-12-01 15:26, jdd wrote:

Le 01/12/2016 à 15:22, Carlos E. R. a écrit :

...

I have no idea if/how that is possible.

a coredump may hold sensitive infos.

Mr Root always can read your core dumps and your memory.

I was dumbly thinking a developer uses his own computer :-(

Well... I can imagine scenarios. If you are a student and use a school/college computer, administered by the lab chief, you have to call him to get access to your own cores. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Thursday 01 December 2016, Carlos E. R. wrote:

On 2016-12-01 15:26, jdd wrote:

...

Le 01/12/2016 à 15:22, Carlos E. R. a écrit :

...

I have no idea if/how that is possible.

a coredump may hold sensitive infos.

Mr Root always can read your core dumps and your memory.

...

I was dumbly thinking a developer uses his own computer :-(

Well... I can imagine scenarios. If you are a student and use a school/college computer, administered by the lab chief, you have to call him to get access to your own cores.

On my systems the user has read access (ACL) to it's coredump. So this is no problem. More bad it is that the user can't delete it's own coredump and also not disable it by ulimit. And the user can exceed his disk quota by producing coredumps. I'm using the better "cordubla" for all our systems. It also creates symlinks in the CWD so that the users easiely find their coredumps as usually http://software.opensuse.org/download.html?project=home%3Arudi_m&package=cordubla cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/01/2016 10:08 PM, Per Jessen wrote:

Ruediger Meier wrote:

...

On Thursday 01 December 2016, Carlos E. R. wrote:

...

On 2016-12-01 15:26, jdd wrote:

...

Le 01/12/2016 à 15:22, Carlos E. R. a écrit :

...

I have no idea if/how that is possible. a coredump may hold sensitive infos. Mr Root always can read your core dumps and your memory.

...

I was dumbly thinking a developer uses his own computer :-( Well... I can imagine scenarios. If you are a student and use a school/college computer, administered by the lab chief, you have to call him to get access to your own cores. On my systems the user has read access (ACL) to it's coredump. So this is no problem.

More bad it is that the user can't delete it's own coredump and also not disable it by ulimit. And the user can exceed his disk quota by producing coredumps. With the default setup in Leap422, afaict user coredumps are disabled by default, and I don't see how the user can exceed his quota when systemd is handling it.

For me systemd coredumps were enabled by default and work as user. So my users are able to fill the hardisk with cordumps. The user's quota is ignored because systemd core dumps are owned by root. That's wrong IMO. Also systemd-coredump should respect the ulimit -c settings (That's what the %c argument would be used for). So if you have a 50G process crashing then this core dumper would probably write the whole 50G to disk. I guess the machine would slow down for hours because by default it even uses xz compression. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/01/2016 11:19 PM, Carlos E. R. wrote:

On 2016-12-01 23:02, Ruediger Meier wrote:

...

For me systemd coredumps were enabled by default and work as user. So my users are able to fill the hardisk with cordumps. The user's quota is ignored because systemd core dumps are owned by root. That's wrong IMO.

Also systemd-coredump should respect the ulimit -c settings (That's what the %c argument would be used for). So if you have a 50G process crashing then this core dumper would probably write the whole 50G to disk. I guess the machine would slow down for hours because by default it even uses xz compression. Well, instead you have to set limits in "/usr/lib/sysctl.d/50-coredump.conf". You can configure the single core max size in bytes and total size in % of disk size.

Only root can do that. Also it makes no sense to invent another config setting although we've had a more powerful one by default in past.

The settings I posted on another email.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Dec 2, 2016 at 7:13 AM, Andrei Borzenkov wrote:

02.12.2016 01:02, Ruediger Meier пишет:

...

Also systemd-coredump should respect the ulimit -c settings (That's what

This limit is for kernel. Systemd does not decide whether to create core or not - it just stores (and possibly preprocesses) it if it was created.

...

the %c argument would be used for). So if you have a 50G process

If core exceeds ulimit -c, it is not created at all and systemd-coredump does not see it. So how exactly it would be useful here?

I stay corrected. Linux kernel ignores ulimit -c when core_pattern is set to pipe; so yes, it is useful and is actually honored by systemd as of version 229 upstream. If this is not included in Leap 42.2, it is good candidate for bug report.

...

crashing then this core dumper would probably write the whole 50G to disk. I guess the machine would slow down for hours because by default it even uses xz compression.

ProcessSizeMax= The maximum size in bytes of a core which will be processed. Core dumps exceeding this size will be logged, but the backtrace will not be generated and the core will not be stored.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2016-12-01 14:14, Patrick Shanahan wrote:

...

* Per Jessen [12-01-16 04:08]:

...

Judging by /proc/sys/kernel/core_pattern, it looks like systemd is now somehow dealing with MY core dump?

# cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

It appears to end up in /var/lib/systemd/coredump, where I can read the files, but I cannot delete them? Seems like everybody else can read it - that's surely not right?

This appears to be new in Leap422 - in Leap421, we had just 'core':

# cat /proc/sys/kernel/core_pattern core

appears same in Tw: 08:11 Crash:~ > cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

and ends in /var/lib/systemd/coredump/ but as root I can delete them

But not as the user of the application that dumped core.

If you are a developer working in some software that dumps core, you can not analyze your own software problem.

Well, yes, that works - the ACL takes care of that. -- Per Jessen, Zürich (1.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 2016-12-01 17:49, Per Jessen wrote:

Patrick Shanahan wrote:

...

appears same in Tw: 08:11 Crash:~ > cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

Somebody knows what means those options? cer@Telcontar:~> man systemd-coredump No manual entry for systemd-coredump cer@Telcontar:~> I would guess that %u is "user" and "%g" is group. Probably they are parameter substitution for something else. If we find that out, perhaps we can write our own configuration to that proc file.

...

and ends in /var/lib/systemd/coredump/ but as root I can delete them

Yep, same here. I find a pretty odd setup, I have to say. What's the point in storing a user-level coredump outside the current dir. Not to mention letting any other user read them.

They can not, unless they are on the root group. At least here. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-12-01 20:43, Ruediger Meier wrote:

On 12/01/2016 07:39 PM, Carlos E. R. wrote:

...

On 2016-12-01 17:49, Per Jessen wrote:

...

Patrick Shanahan wrote:

...

...

appears same in Tw: 08:11 Crash:~ > cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e Somebody knows what means those options? man core

Thanks :-) %p PID of dumped process %P ?? %u (numeric) real UID of dumped process %g (numeric) real GID of dumped process %s number of signal causing dump %t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC) %e executable filename (without path prefix) Now we need to know where the documentation for "systemd-coredump" is. I don't have a man page. Ah, yes, I do, on a newer system: DESCRIPTION systemd-coredump can be used as a helper binary by the kernel when a user space program receives a fatal signal and dumps core. For it to be used in this capacity, it must be specified by the kernel.core_pattern sysctl(8) setting. Systemd installs /usr/lib/sysctl.d/50-coredump.conf which configures kernel.core_pattern to invoke systemd-coredump. This file may be masked or overridden to use a different setting following normal sysctl.d(5) rules. The behavior of a specific program upon reception of a signal is governed by a few factors which are described in detail in core(5). In particular, the coredump will only be processed when the related resource limits are high enough. For programs started by systemd, those may be set using LimitCore= (see systemd.exec(5)). systemd-coredump will log the coredump including a backtrace if possible, and store the core (contents of process' memory contents) in an external file on disk in /var/lib/systemd/coredump, or directly in the journal. This behavior may be modified using coredump.conf(5). Apart from the journalctl(1) log viewer, coredumpctl(1) may be used to list and extract coredumps. And there is a corresponding coredump.conf and manual. Isengard:~ # cat /usr/lib/sysctl.d/50-coredump.conf # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # See sysctl.d(5) for the description of the files in this directory, # and systemd-coredump(8) and core(5) for the explanation of the # setting below. kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e Isengard:~ # Let's see the manual: OPTIONS All options are configured in the "[Coredump]" section: Storage= Controls where to store cores. One of "none", "external", "journal", and "both". When "none", the coredumps will be logged but not stored permanently. When "external" (the default), cores will be stored in /var/lib/systemd/coredump. When "journal", cores will be stored in the journal and rotated following normal journal rotation patterns. When "both", cores will be stored in both locations. When cores are stored in the journal, they might be compressed following journal compression settings, see journald.conf(5). When cores are stored externally, they will be compressed by default, see below. Compress= Controls compression for external storage. Takes a boolean argument, which defaults to "yes". ProcessSizeMax= The maximum size in bytes of a core which will be processed. Coredumps exceeding this size will be logged, but the backtrace will not be generated and the core will not be stored. ExternalSizeMax=, JournalSizeMax= The maximum (uncompressed) size in bytes of a core to be saved. MaxUse=, KeepFree= Enforce limits on the disk space taken up by externally stored coredumps. MaxUse= makes sure that old coredumps are removed as soon as the total disk space taken up by coredumps grows beyond this limit (defaults to 10% of the total disk size). KeepFree= controls how much disk space to keep free at least (defaults to 15% of the total disk size). Note that the disk space used by coredumps might temporarily exceed these limits while coredumps are processed. Note that old coredumps are also removed based on time via systemd-tmpfiles(8). Set either value to 0 to turn off size-based clean-up. Mmmm... Seems "MaxUse" is a percent, not a size. Ageing is controlled by systemd-tmpfiles, configured where? Maybe a file in "/usr/lib/tmpfiles.d/ Isengard:~ # grep core /usr/lib/tmpfiles.d/* /usr/lib/tmpfiles.d/systemd.conf:d /var/lib/systemd/coredump 0755 root root 3d Isengard:~ # Ok, so the line is d /var/lib/systemd/coredump 0755 root root 3d man tmpfiles.d The configuration format is one line per path containing type, path, mode, ownership, age, and argument fields. The permissions apply to the directory, not the contents. And they are deleted after 3 days. Still, I do not see how to control the permissions of the core files. But the line kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e would allow to set it differently to some other command. Perhaps create our own script. In 13.1 it is: cer@Telcontar:~> cat /proc/sys/kernel/core_pattern core cer@Telcontar:~> So, perhaps from this information some one can think a way to customize the permissions. I don't object to have cores centralized in a directory. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-12-02 05:02, Andrei Borzenkov wrote:

02.12.2016 00:12, Carlos E. R. пишет:

...

...

...

...

...

appears same in Tw: 08:11 Crash:~ > cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e Somebody knows what means those options? man core

Thanks :-)

%p PID of dumped process %P ??

%P PID of dumped process, as seen in the initial PID namespace (since Linux 3.12)

So %p is the same as %P? The manual I read does not say.

...

Still, I do not see how to control the permissions of the core files.

Core files created by systemd are expected to be root:root with permissions 640 and additional ACL to allow process owner to read them.

Yes, I saw the ACLs later

Why is it not sufficient and how you want to change it?

To allow the user to delete his cores. By the way, I had 4 coredumps of several processes in 2 days on my single 42.2 install. More than I have seen in months on other releases. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlhA+IcACgkQja8UbcUWM1zULQD/QdjGOhuY3UoOtDwYCDYBGjUY 4Eh0WjBE2+aArXGqjEsA/ipiYiFMikbzDteFn1k7inu2YZlm1wsyOuaYRHs5P2/4 =Dh5F -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-12-02 07:43, Andrei Borzenkov wrote:

On Fri, Dec 2, 2016 at 7:28 AM, Carlos E. R. <> wrote:

...

...

...

%p PID of dumped process %P ??

%P PID of dumped process, as seen in the initial PID namespace (since Linux 3.12)

So %p is the same as %P? The manual I read does not say.

%p is PID in process namespace. Which may or may not be the same as %P.

Ah...

...

...

...

Still, I do not see how to control the permissions of the core files.

Core files created by systemd are expected to be root:root with permissions 640 and additional ACL to allow process owner to read them.

Yes, I saw the ACLs later

...

Why is it not sufficient and how you want to change it?

To allow the user to delete his cores.

Welcome to the wonderful world of Unix permissions that force (each) program to jump through the hoops to implement what would normally need a single ACE on corresponding file.

That said, I suppose "coredumpctl delete" patch has some chances to be accepted.

Huh. No, don't expect that one from me. Outside my possibilities ;-)

...

By the way, I had 4 coredumps of several processes in 2 days on my single 42.2 install. More than I have seen in months on other releases.

Not sure what you try to say with it.

Just saying :-) That I have seen too many cores in 42.2, something is wrong somewhere. Either 42.2 is not-stable, or 13.1 ate the coredumps without writing them. Or I didn't see where they were. Yes, after noticing there was a core dump, previously one had to seek its location. I like having them in a central point, at least as long as I'm Mr Root ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Carlos E. R. wrote:

On 2016-12-01 17:49, Per Jessen wrote:

...

Patrick Shanahan wrote:

...

...

appears same in Tw: 08:11 Crash:~ > cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

Somebody knows what means those options?

cer@Telcontar:~> man systemd-coredump No manual entry for systemd-coredump

That man-page _is_ present, I have it.

If we find that out, perhaps we can write our own configuration to that proc file.

You can do that anytime, I have already reverted to "core.%p".

...

Yep, same here. I find a pretty odd setup, I have to say. What's the point in storing a user-level coredump outside the current dir. Not to mention letting any other user read them.

They can not, unless they are on the root group. At least here.

Ah okay. The core dumps have ACLs, I guess only the user that produced it can read it. I'd still like to understand the reasoning for making this the default. It seems utterly superfluous. Why do user coredumps have to be handled by systemd and stored under /var/lib/systemd/coredump ? -- Per Jessen, Zürich (1.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

Carlos E. R. wrote:

...

...

If we find that out, perhaps we can write our own configuration to that proc file.

You can do that anytime, I have already reverted to "core.%p".

See my last message, you can make that permanent.

Sure - /etc/sysctl.conf

...

I'd still like to understand the reasoning for making this the default. It seems utterly superfluous. Why do user coredumps have to be handled by systemd and stored under /var/lib/systemd/coredump ?

To have them centralized, so that the admin sees easily how much space is used/wasted by cores.

That does not sounds like a very good reason. Not convincing at all. -- Per Jessen, Zürich (-1.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

Carlos E. R. wrote:

On 2016-12-02 07:37, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

...

If we find that out, perhaps we can write our own configuration to that proc file.

You can do that anytime, I have already reverted to "core.%p".

See my last message, you can make that permanent.

Sure - /etc/sysctl.conf

No, it is:

/usr/lib/sysctl.d/50-coredump.conf

It's probably overriden by sysctl.conf. Anyway, 50-coredump.conf is also new in leap422.

...

...

...

I'd still like to understand the reasoning for making this the default. It seems utterly superfluous. Why do user coredumps have to be handled by systemd and stored under /var/lib/systemd/coredump ?

To have them centralized, so that the admin sees easily how much space is used/wasted by cores.

That does not sounds like a very good reason. Not convincing at all.

Previously, I had to run "updatedb ; locate core" to find them.

Yesterday it took me about an hour to figure that systemd was hijacking my core dumps :-) I think it's a poor default. -- Per Jessen, Zürich (2.6°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

02.12.2016 00:17, Per Jessen пишет:

Ah okay. The core dumps have ACLs, I guess only the user that produced it can read it. I'd still like to understand the reasoning for making this the default. It seems utterly superfluous. Why do user coredumps have to be handled by systemd and stored under /var/lib/systemd/coredump ?

You apparently never had to hunt for core dump of some obscure program crashing without knowing which directory this program happened to be at the time of crash. Having coredumps is one central place is much more convenient. It is also not something new; e.g. Ubuntu was feeding coredumps to apport long before systemd. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Dec 2, 2016 at 9:42 AM, Per Jessen wrote:

I see the point for system apps, but I really think systemd ought to let _me_ decide where _my_ core dumps go.

It's not like it is set in stone and it is trivial to change so what's your point exactly? If you think it should have better coverage in release notes or that defaults should be changed - open bug report. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Andrei Borzenkov wrote:

...

On Fri, Dec 2, 2016 at 9:42 AM, Per Jessen wrote:

...

I see the point for system apps, but I really think systemd ought to let _me_ decide where _my_ core dumps go.

It's not like it is set in stone and it is trivial to change so what's your point exactly? If you think it should have better coverage in release notes or that defaults should be changed - open bug report.

I know, I probably will. Until I do, it seems reasonable to discuss it and see what other people think. (perhaps that should have been done it was changed ...)

... before it was changed. Anyway, https://bugzilla.opensuse.org/show_bug.cgi?id=1013210 -- Per Jessen, Zürich (0.9°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

david allan finch wrote:

If you are a developer add the following in you code and it will override the system built it stuff. The core file will be in the directory you are run the process, just like it used to. You might want to have some form of flag say -core to enable it.

Hi David fyi, the core file still ends up in /var/lib/systemd/coredump. setrlimit isn't able to change the location, afaict. /Per

----8<---- void my_allow_coredumps() { #if defined(__SVR4) || defined(__linux) struct rlimit limits; limits.rlim_cur = limits.rlim_max = RLIM64_INFINITY; setrlimit(RLIMIT_CORE, &limits); #endif }

int main( int argc, char* argv[] ) { my_allow_coredumps() } ----8<----

-- Per Jessen, Zürich (3.0°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