From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2013-March/023907.html | 175 ++++++++++++++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100644 zarb-ml/mageia-dev/2013-March/023907.html (limited to 'zarb-ml/mageia-dev/2013-March/023907.html') diff --git a/zarb-ml/mageia-dev/2013-March/023907.html b/zarb-ml/mageia-dev/2013-March/023907.html new file mode 100644 index 000000000..f744578d1 --- /dev/null +++ b/zarb-ml/mageia-dev/2013-March/023907.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] Apache doesn't always like restarting.... + + + + + + + + + +

[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
+ -- cgit v1.2.1