[Mageia-dev] Apache doesn't always like restarting....

Colin Guthrie mageia at colin.guthr.ie
Thu Mar 28 00:12:13 CET 2013


'Twas brillig, and AL13N at 27/03/13 18:46 did gyre and gimble:
> Op woensdag 27 maart 2013 15:44:48 schreef Guillaume Rousse:
>> Le 27/03/2013 15:09, AL13N a écrit :
>>> the other day i tried to get cores, but somehow unlimited meant 0 meant no
>>> core at all
>>
>> You need to set LimitCORE=infinity in unit file, according to
>> systemd.exec man page. And you probably need the adequate sysctl setting
>> (kernel.core_pattern) to ensure the core file get dumped into a
>> predictible directory.
> 
> actually, no, setting LimitCORE=infinity (also our default as shown with 
> systemctl show *.service) ends up with the actual limit being 0 as shown by 
> prlimit. (this was with help from #systemd people)

Can you point at a commit that fixes this then. I'm a little confused as
I've used this setup to happily get segv's from apache (namely php) so
I'm a little confused as to why it doesn't work for you :s

Even running prlimit here, I don't see a problem:

[colin at jimmy scripts (master)]$ ps aux | grep httpd
root      4576  0.0  0.2 413372 21936 ?        Ss   19:41   0:00
/usr/sbin/httpd -DFOREGROUND
apache    4577  0.0  0.3 426024 30288 ?        S    19:41   0:00
/usr/sbin/httpd -DFOREGROUND
apache    4579  0.0  0.1 413804 14408 ?        S    19:41   0:00
/usr/sbin/httpd -DFOREGROUND
apache    4581  0.0  0.1 414012 15680 ?        S    19:41   0:00
/usr/sbin/httpd -DFOREGROUND
apache    4582  0.0  0.1 413804 14312 ?        S    19:41   0:00
/usr/sbin/httpd -DFOREGROUND
apache    4583  0.0  0.1 413812 14380 ?        S    19:41   0:00
/usr/sbin/httpd -DFOREGROUND
apache    4584  0.0  0.4 434512 38160 ?        S    19:41   0:00
/usr/sbin/httpd -DFOREGROUND
apache    4585  0.0  0.4 434488 38140 ?        S    19:41   0:00
/usr/sbin/httpd -DFOREGROUND
apache    4586  0.0  0.1 413804 14344 ?        S    19:41   0:00
/usr/sbin/httpd -DFOREGROUND
[colin at jimmy scripts (master)]$ prlimit -c -p 4576
prlimit: failed to get the CORE resource limit: Operation not permitted
[colin at jimmy scripts (master)]$ sudo prlimit -c -p 4576
RESOURCE DESCRIPTION             SOFT      HARD UNITS
CORE     max core file size unlimited unlimited blocks
[colin at jimmy scripts (master)]$ sudo prlimit -c -p 4577
RESOURCE DESCRIPTION             SOFT      HARD UNITS
CORE     max core file size unlimited unlimited blocks



Are you absolutely sure it's not just apache resetting the value when
you don't set CoreDumpDirectory in your httpd.conf?


> moreover, the systemd is compiled without coredump functionality, and that 
> seems to have an effect on this and disallows one to configure systemd-coredump 
> (which isn't build nor packaged) for usage with integrated coredumps with the 
> systemd-coredump-ctl executable, (which is packaged).

This was a deliberate decision at the time. There were not sufficient
tools to extract coredumps from the journal logs and really the coredump
support should be separate from the coredump capturing and logging to
the journal anyway, so it shouldn't affect anything you're doing right
now (e.g. it shouldn't affect how you setup apache)

The fact that systemd-coredump-ctl is build is IMO a bug, and one that
could very well be fixed upstream already (probably is) but I didn't
want to keep the rm in the %install section of the spec lest it was
accidentally left in there when we turn the feature on (when it's
generally more useful - i.e. you can store cores in a directory outside
of the journal etc etc.).

> @colin, so please, fix these 2 issues (first one looks like a systemd issue; 
> while the second one is a packaging issue)

Like I say I've not actually observed the first problem personally, and
have actively gotten core files from apache and my prlimit settings seem
to be different from yours so I'm not really sure what to solve.


As for the core dump support, I would be happy enough re-enabling it
again. I'm just not convinced that storing the dumps in the journal is a
great idea. I mean if you get a constantly crashing service, your logs
will fill up quickly and be rotated away quickly. I think the cores
should be stored outside of the journal. I can't remember off hand if
the patch that implemented this was finally committed or not - I'll have
a look and check.

Col



-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/


More information about the Mageia-dev mailing list