November 2019 - Arch-general - lists.archlinux.org

[arch-general] 11/23 update caused httpd to coredump?
by David C. Rankin 04 Dec '19

04 Dec '19

Dev, This is a strange one. After updates on 11/23, httpd began segfaulting -- repeatedly: > l /var/log/httpd/error_log* -rw-r--r-- 1 root root 24306171 Nov 24 14:48 /var/log/httpd/error_log -rw-r--r-- 1 root root 625 Nov 24 00:00 /var/log/httpd/error_log.1 -rw-r--r-- 1 root root 1742 Nov 21 13:19 /var/log/httpd/error_log.2 -rw-r--r-- 1 root root 504 Nov 10 00:00 /var/log/httpd/error_log.3 -rw-r--r-- 1 root root 1754 Nov 3 00:00 /var/log/httpd/error_log.4 I have a second server that confirms this exact same behavior: > l /var/log/httpd/error_log* -rw-r--r-- 1 root root 25049142 Nov 24 14:48 /var/log/httpd/error_log -rw-r--r-- 1 root root 1137 Nov 24 00:00 /var/log/httpd/error_log.1 -rw-r--r-- 1 root root 1752 Nov 17 00:01 /var/log/httpd/error_log.2 -rw-r--r-- 1 root root 504 Nov 10 00:00 /var/log/httpd/error_log.3 -rw-r--r-- 1 root root 1754 Nov 3 00:01 /var/log/httpd/error_log.4 The log file size jumped from 625 bytes to 24306171 bytes (1137->25049142 on the other server) in just a matter of hours. The old log contains, in its entirety: > cat error_log.1 [Thu Nov 21 13:39:09.090480 2019] [suexec:notice] [pid 898] AH01232: suEXEC mechanism enabled (wrapper: /usr/bin/suexec) [Thu Nov 21 13:39:09.146764 2019] [lbmethod_heartbeat:notice] [pid 898] AH02282: No slotmem from mod_heartmonitor [Thu Nov 21 13:39:09.378344 2019] [mpm_prefork:notice] [pid 898] AH00163: Apache/2.4.41 (Unix) OpenSSL/1.1.1d PHP/5.6.40 configured -- resuming normal operations [Thu Nov 21 13:39:09.378406 2019] [core:notice] [pid 898] AH00094: Command line: '/usr/bin/httpd -D FOREGROUND' [Sun Nov 24 00:00:27.074145 2019] [mpm_prefork:notice] [pid 898] AH00171: Graceful restart requested, doing restart The new log began with: > head error_log [Sun Nov 24 00:00:27.104644 2019] [lbmethod_heartbeat:notice] [pid 898] AH02282: No slotmem from mod_heartmonitor [Sun Nov 24 00:00:27.115890 2019] [mpm_prefork:notice] [pid 898] AH00163: Apache/2.4.41 (Unix) OpenSSL/1.1.1d PHP/5.6.40 configured -- resuming normal operations [Sun Nov 24 00:00:27.115901 2019] [core:notice] [pid 898] AH00094: Command line: '/usr/bin/httpd -D FOREGROUND' [Sun Nov 24 00:00:28.120350 2019] [core:notice] [pid 898] AH00051: child pid 11154 exit signal Segmentation fault (11), possible coredump in /etc/httpd [Sun Nov 24 00:00:28.120576 2019] [core:notice] [pid 898] AH00051: child pid 11156 exit signal Segmentation fault (11), possible coredump in /etc/httpd [Sun Nov 24 00:00:28.120728 2019] [core:notice] [pid 898] AH00051: child pid 11158 exit signal Segmentation fault (11), possible coredump in /etc/httpd [Sun Nov 24 00:00:28.120871 2019] [core:notice] [pid 898] AH00051: child pid 11160 exit signal Segmentation fault (11), possible coredump in /etc/httpd [Sun Nov 24 00:00:28.121060 2019] [core:notice] [pid 898] AH00051: child pid 11162 exit signal Segmentation fault (11), possible coredump in /etc/httpd [Sun Nov 24 00:00:30.126762 2019] [core:notice] [pid 898] AH00051: child pid 11253 exit signal Segmentation fault (11), possible coredump in /etc/httpd Updating again today (which is when I caught the problem), and restarting httpd has solved whatever problem there was and httpd is now happily running fine again. The only updates that occurred on the 23rd and 24th are as follows and nothing jumps out as being a problem: [2019-11-23T03:35:07-0600] [PACMAN] starting full system upgrade [2019-11-23T03:36:09-0600] [ALPM] transaction started [2019-11-23T03:36:09-0600] [ALPM] upgraded libusbmuxd (1.0.10+29+g9db5747-1 -> 2.0.0-2) [2019-11-23T03:36:09-0600] [ALPM] upgraded libimobiledevice (1.2.0+87+g92c5462-5 -> 1.2.0+87+g92c5462-6) [2019-11-23T03:36:10-0600] [ALPM] upgraded nodejs (13.1.0-2 -> 13.2.0-1) [2019-11-23T03:36:16-0600] [ALPM] upgraded python2-typing (3.6.6-1 -> 3.7.4.1-1) [2019-11-23T03:36:16-0600] [ALPM] upgraded qpdf (9.0.2-1 -> 9.1.0-1) [2019-11-23T03:36:17-0600] [ALPM] transaction completed [2019-11-23T03:36:17-0600] [ALPM] running '30-systemd-update.hook'... [2019-11-24T14:39:58-0600] [PACMAN] Running 'pacman -Syu' [2019-11-24T14:39:58-0600] [PACMAN] synchronizing package lists [2019-11-24T14:40:00-0600] [PACMAN] starting full system upgrade [2019-11-24T14:40:31-0600] [ALPM] transaction started [2019-11-24T14:40:31-0600] [ALPM] upgraded blas (3.8.0-2 -> 3.9.0-2) [2019-11-24T14:40:31-0600] [ALPM] upgraded cblas (3.8.0-2 -> 3.9.0-2) [2019-11-24T14:40:33-0600] [ALPM] upgraded mesa (19.2.4-1 -> 19.2.6-1) [2019-11-24T14:40:33-0600] [ALPM] upgraded xorg-server-common (1.20.5-4 -> 1.20.6-1) [2019-11-24T14:40:33-0600] [ALPM] upgraded libutil-linux (2.34-6 -> 2.34-8) [2019-11-24T14:40:33-0600] [ALPM] upgraded util-linux (2.34-6 -> 2.34-8) [2019-11-24T14:40:33-0600] [ALPM] upgraded xorg-server (1.20.5-4 -> 1.20.6-1) [2019-11-24T14:40:39-0600] [ALPM] upgraded nvidia-utils (440.31-1 -> 440.36-1) [2019-11-24T14:40:39-0600] [ALPM-SCRIPTLET] If you run into trouble with CUDA not being available, run nvidia-modprobe first. [2019-11-24T14:40:39-0600] [ALPM] upgraded eglexternalplatform (1.0+3+g7c8f8e2-1 -> 1.1-1) [2019-11-24T14:40:39-0600] [ALPM] upgraded egl-wayland (1.1.4-1 -> 1.1.4-2) [2019-11-24T14:40:39-0600] [ALPM] upgraded faad2 (2.9.1-1 -> 2.9.1-2) [2019-11-24T14:40:39-0600] [ALPM] upgraded graphviz (2.42.2-6 -> 2.42.3-1) [2019-11-24T14:40:40-0600] [ALPM] upgraded lapack (3.8.0-2 -> 3.9.0-2) [2019-11-24T14:40:41-0600] [ALPM] upgraded libmagick6 (6.9.10.71-1 -> 6.9.10.74-1) [2019-11-24T14:40:41-0600] [ALPM] upgraded libwpe (1.4.0-1 -> 1.4.0.1-1) [2019-11-24T14:40:41-0600] [ALPM] upgraded man-pages (5.03-2 -> 5.04-1) [2019-11-24T14:40:41-0600] [ALPM] upgraded perl-libwww (6.41-1 -> 6.42-1) [2019-11-24T14:40:41-0600] [ALPM] upgraded python-pyasn1 (0.4.7-3 -> 0.4.8-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded python-setuptools (1:41.4.0-1 -> 1:41.6.0-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded python2-pyasn1 (0.4.7-3 -> 0.4.8-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded python2-setuptools (1:41.4.0-1 -> 1:41.6.0-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded qhull (2019.1-1 -> 2019.1-2) [2019-11-24T14:40:42-0600] [ALPM] upgraded tcl (8.6.9-2 -> 8.6.10-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded tk (8.6.9.1-2 -> 8.6.10-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded vte-common (0.58.2-1 -> 0.58.3-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded vte3 (0.58.2-1 -> 0.58.3-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded wpebackend-fdo (1.4.0-1 -> 1.4.0-2) [2019-11-24T14:40:42-0600] [ALPM] upgraded xorg-server-devel (1.20.5-4 -> 1.20.6-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded yelp-xsl (3.34.0-1 -> 3.34.2-1) [2019-11-24T14:40:43-0600] [ALPM] transaction completed [2019-11-24T14:40:43-0600] [ALPM] running '20-systemd-sysusers.hook'... [2019-11-24T14:40:43-0600] [ALPM] running '30-systemd-daemon-reload.hook'... [2019-11-24T14:40:43-0600] [ALPM] running '30-systemd-udev-reload.hook'... [2019-11-24T14:40:43-0600] [ALPM] running '30-systemd-update.hook'... [2019-11-24T14:40:43-0600] [ALPM] running 'detect-old-perl-modules.hook'... Nothing really looks like it should directly implicate httpd. But after the first graceful restart of the server after the 5 packages were updated on 11/23 cause httpd to go haywire. Just thought I would pass it along. -- David C. Rankin, J.D.,P.E.

3 5

[arch-general] python-cmake?
by Iyán Méndez Veiga 29 Nov '19

29 Nov '19

Hi, First of all, sorry if this is a really stupid question, but I've been trying to search for a while and I couldn't find an answer. Is the python module 'cmake' provided in some package in Arch? I mean, I know that there is the cmake package in [extra] but there is no python-cmake, and when I try 'import cmake' of course the module is not found. This works if I install cmake with pip: $ python -m env test $ source test/bin/activate $ (test) pip install cmake $ (test) python $>>> import cmake Thanks, Iyán

4 8

[arch-general] about ecryptfs-utils, openssl supporting should be added ?
by Yi Zheng 28 Nov '19

28 Nov '19

why not add '--enable-openssl' into the configure options? Does it support OpenSSL now?

4 3

[arch-general] Fedora Speeds Up Python 3.
by Ralph Corderoy 27 Nov '19

27 Nov '19

Hi, I thought this might be of interest. https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup By building with -fno-semantic-interposition they remove the PLT that provides a level of indirection when calling a libpython function. libpython often calls itself and the PLT adds L1-cache pressure plus prevents inlining. Gives gains of 25% on some workloads. -- Cheers, Ralph.

3 3

Re: [arch-general] [aur-general] [PRQ#16805] Deletion Request for the-darkmod-tweaked
by Jerome Leclanche 26 Nov '19

26 Nov '19

On Tue, Nov 26, 2019 at 3:28 PM Alberto Salvia Novella via aur-general < aur-general(a)archlinux.org> wrote: > … I've had quite enough of these emails. Eli's actions are nearly unanimously supported by the other TUs. You've consistently behaved inappropriately in mailing lists, on the forums and you've several times tried shipping dangerous code to users. You've tested everyone's patience and you're now out of time. I'm honestly surprised you're not banned from the ML (yet?). Move on. J. Leclanche

1 0

[arch-general] calibre is now available in python3
by Eli Schwartz 25 Nov '19

25 Nov '19

After about 15 months of gradual work by me and a few other people, https://calibre-ebook.com/ is running pretty stably on python3, so I've uploaded a split package to [community]: calibre (the default python2 build), calibre-python3 (a python3 build, naturally), and calibre-common with some common files. Hopefully this will get rid of one of our major python2 consumers soon. Upstream doesn't officially support this yet, so treat it like the pre-beta it is. You'll also be unable to use thirdparty plugins, since none of those are ported yet, so you may want to have both 'calibre-python3' and 'calibre' installed -- since pacman still doesn't have support for an "alternatives" feature, I've written a dumb shell script to do the work of switching between the two, see `calibre-alternatives help` for details (it is in the calibre-common package). General information about the port and its status can be found here: https://github.com/kovidgoyal/calibre/pull/870 At some point soon upstream will finish making cross-platform betas and plugins will start to be ported by their developers, so watch this space (and the mobileread.com forums) for more info... Bug reports for python3 regressions will be greatly appreciated, as there are probably a lot of fun edge cases and I'd like to see this finished sooner rather than later. ;) -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-general] Many timers now running at boot. How to make them run later?
by David C. Rankin 23 Nov '19

23 Nov '19

After not booting an Arch box for several days, the first few minutes seem quite MS like lately with a flurry of processes running to the point after I enter my username at the console, it may be 10-20 sec before the password prompt is displayed. Since it's all timers now and not cron running things quietly at 4:00 am, this loads sever processes right at boot that cause the problem. For example, boot just now was crawling and checking systemctl timers shows: (leading columns snipped) LAST PASSED UNIT ACTIVATES n/a n/a systemd-tmpfiles-clean.timer systemd-t> Thu 2019-11-21 03:33:43 CST 11min ago logrotate.timer logrotate> Thu 2019-11-21 03:33:43 CST 11min ago man-db.timer man-db.se> Thu 2019-11-21 03:33:43 CST 11min ago shadow.timer shadow.se> 4 timers listed. Pass --all to see loaded but inactive timers, too. This impacts being able to get thins from a computer in a hurry and reminds me of the unpleasant waits waiting for windows to run all of its on-boot checks. What is the best way to modify this scheme to prevent, e.g. logrotate.time, man-db.timer and shadow.timer all trying to run on boot? I'd rather set them up to run a 5:00 localtime as I would with cronnie. But I do want to use the systemd timer, so what is the best way to configure the systemd timer to schedule these things to run at a convenient time instead of all firing on boot? -- David C. Rankin, J.D.,P.E.

6 9

[arch-general] Disable pam_securetty.so
by Daan De Meyer 22 Nov '19

22 Nov '19

Hi, I don't want to come across as impatient but I was wondering how I can accelerate handling of this particular issue: https://bugs.archlinux.org/task/45903?project=1&string=pam I've listed examples in the issue that pam_securetty has been disabled on other major distros. The main issue is that it prevents root login on systemd-nspawn containers. It should be easy to remove and there's a precedence in other distros. Any tips on how to proceed to get this fixed? Regards, Daan

2 1

[arch-general] issue with i915
by Enrique Pérez Arnaud 21 Nov '19

21 Nov '19

Hi, I am experiencing some issue with the i915 driver. The symptom is hangups of the graphic environment every few minutes, lasting for a couple of seconds. When they happen, journalctl shows a log entry like: Nov 14 12:39:46 eperez-ws kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0 This seems to be reported [1] but I don't see any solution there. Does anyone know of some solution for this? Thanks in advance, and have a nice day :) 1.- https://gitlab.freedesktop.org/mesa/mesa/issues/1837 -- Enrique Pérez Arnaud enriquepablo(a)gmail.com

2 2

[arch-general] The differences among bootx64.efi, loader.efi and grubx64.efi.
by Hongyi Zhao 20 Nov '19

20 Nov '19

I noticed that for many distro's install iso, there are some efi files in the EFI/efi folder as follows: bootx64.efi, loader.efi and grubx64.efi Say, for arch: bootx64.efi, loader.efi for debian: bootx64.efi grubx64.efi I just cannot figure out the differences among them. Could you please give me some hints on this? Thanks in advance. -- Hongsheng Zhao <hongyi.zhao(a)gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493

3 7