devel

devel@lists.centos.org

6 participants
4663 discussions

CentOS will support openssl 1.1.1 in future version of CentOS
by Maheshwari, Shagun 30 Jan '19

30 Jan '19

Hi, There is a plan from CentOS to support OpenSSL 1.1.1 in future versions of CentOS 7 because openssl community has OpenSSL 1.1.1 which was released in Sep 2018 and it has fixed for many vulnerabilities. And CentOS has 1.0.2k version. Can you please update on this? Regards, Shagun

5 4

Observing deadlock between SIPhandler and SDL Router in CUCM.
by Priya, Nupur 24 Jan '19

24 Jan '19

Observing deadlock between SIPhandler and SDL Router in CUCM. Looks like this is fixed in glibc 2.17.162 version, but we see the issue still https://bugzilla.redhat.com/show_bug.cgi?id=906468 Need help to identify the root cause and add a preventive fix. Here is the error messages: *********************************************************************************************************************************************************************************************************************************** gdb) thread 40 [Switching to thread 40 (Thread 0xaca90b40 (LWP 5935))] #3 0xf67fdbd1 in malloc () from /usr/lib/libc.so.6 (gdb) bt #0 0xf775a430 in __kernel_vsyscall () #1 0xf688d462 in __lll_lock_wait_private () from /usr/lib/libc.so.6 #2 0xf68006c0 in _L_lock_14246 () from /usr/lib/libc.so.6 #3 0xf67fdbd1 in malloc () from /usr/lib/libc.so.6 #4 0xf6a68907 in operator new(unsigned int) () from /usr/local/cm/lib/libstlport.so.5.2 #5 0x0936c3f9 in operator() (this=0xaca8dd70) at /view/BLD-cm_12_5_1-cct-ccm-d/vob/ccm/Common/Include/Utilities/Member.hpp:52 #6 c_str (this=0xaca8dd70) at /view/BLD-cm_12_5_1-cct-ccm-d/vob/ccm/Common/Include/CallManager/TDCLCpShares.hpp:862 #7 assign (len=12, digits=0xaca8de34 "+19570676705", this=0xaca8dd70) at /view/BLD-cm_12_5_1-cct-ccm-d/vob/ccm/Common/Include/CallManager/TDCLCpShares.hpp:1252 #8 CdPNumStringVar::CdPNumStringVar (this=0xaca8dd70, digits=0xaca8de34 "+19570676705", len=12) at /view/BLD-cm_12_5_1-cct-ccm-d/vob/ccm/Common/Include/CallManager/TDCLCpShares.hpp:846 #9 0x092efdf8 in SIPCdpc::processSIPSetupMsg (this=this@entry=0x7de0c8e0, sipContainerWrapper=sipContainerWrapper@entry=0x8e966e78) at ProcessSIPCdpc.cpp:2142 #10 0x0934086d in SIPCdpc::processSIPSetupInd (this=this@entry=0x7de0c8e0) at ProcessSIPCdpc.cpp:3300 #11 0x0934ec08 in SIPCdpc::inCall_waitRSVPRes_PolicyAndCACRegisterRes (this=0x7de0c8e0, s= Name : "PolicyAndCACRegisterRes", Sender : spy:PID (8,100,152,1) "ReservationMgr", Receiver : spy:PID (8,100,180,995813) "SIPCdpc", Priority : kNormalPriority) at ProcessSIPCdpc.cpp:26471 #12 0x09e69c7b in SdlProcessBase::inputSignal (this=0x7de0c8e0, rSignal=0x807d8d80, traceType=SdlSystemLog::SignalRouterThread, highPriority=0, normalPriority=0, lowPriority=0, veryLowPriority=0, lazyPriority=0, dbUpdatePriority=0) at SdlProcessBase.cpp:417 #13 0x09e6ce8a in SdlRouter::callProcess (this=this@entry=0xcfff0e0, _sdlSignal=_sdlSignal@entry=0x807d8d80, _deleteSignal=@0xaca8fdb3: true, _traceType=_traceType@entry=SdlSystemLog::SignalRouterThread, _hp=0, _np=0, _lp=0, _vlp=0, _lzp=0, _dbp=0) at SdlRouter.cpp:257 #14 0x09e6d60c in SdlRouter::scheduler (this=this@entry=0xcfff0e0) at SdlRouter.cpp:164 #15 0x09e6dcad in SdlRouter::schedulerInit (sdlRouter=0xcfff0e0) at SdlRouter.cpp:107 #16 0xf69beb3c in start_thread () from /usr/lib/libpthread.so.0 #17 0xf687f44e in clone () from /usr/lib/libc.so.6 (gdb) thread 1 [Switching to thread 1 (Thread 0xa9136b40 (LWP 5964))] #0 0xf67fb876 in _int_malloc () from /usr/lib/libc.so.6 (gdb) bt #0 0xf67fb876 in _int_malloc () from /usr/lib/libc.so.6 #1 0xf67fdbda in malloc () from /usr/lib/libc.so.6 #2 0xf6a68907 in operator new(unsigned int) () from /usr/local/cm/lib/libstlport.so.5.2 #3 0x09cd4ce2 in sip_get_sipspi_message () at sip_common_spi.cpp:20059 #4 0x09cf94d1 in sipTransportPostSendMessage (msg=0x8a20a150, gcb=gcb@entry=0x8015d208, tcb_context=..., connId=24, destAddr=0x8015d228, destPort=5061, transport=SIP_TRANSPORT_TLS_OVER_TCP, emit_debugs=1 '\001', ip_sig_tos=0 '\000') at sip_common_transport.cpp:3032 #5 0x09cf9946 in sipTransportLogicSendMsg (gcb=gcb@entry=0x8015d208, sw_transport=sw_transport@entry=0 '\000') at sip_common_transport.cpp:2367 #6 0x09cfab6f in sipSPITransportSendMessage (msg=msg@entry=0x8a20a150, context=context@entry=0x8015d208, addr=addr@entry=0xa91355dc, port=port@entry=5061, sentBy_port=sentBy_port@entry=0, is_request=is_request@entry=1 '\001', transport=transport@entry=SIP_TRANSPORT_TLS_OVER_TCP, sw_transport=0 '\000', func=func@entry=0x9cb0080 <sentAck(_sipGenericCB*)>, tcb_context=...) at sip_common_transport.cpp:3323 #7 0x09cbe638 in sipSPISendAck (ccb=0x8015d208, flags=flags@entry=0, func=0x9cb0080 <sentAck(_sipGenericCB*)>) at sip_common_send_msg.cpp:2992 #8 0x09ccc910 in sipSPISendAckForMidCallInvite (ccb=0x8015d208, flag=flag@entry=0) at sip_common_spi.cpp:8745 #9 0x09ccdb37 in sact_sent_mid_invite_new_message_response (ccb=0x8015d208, response=0x89305d58) at sip_common_spi.cpp:9278 #10 0x09cda815 in ccsip_spi_process_event (freeEvent=0xa91359df "\001", event=0x7ca43348) at sip_common_spi.cpp:19333 #11 ccsip_process_sipspi_queue_event (event=event@entry=0x7ca43348) at sip_common_spi.cpp:19997 #12 0x093ef758 in SIPHandler::wait_SIPNormalizeRes (this=0xac1c05e8, s= Name : "SIPNormalizeRes", Sender : spy:PID (8,100,184,1) "SIPNormalization", Receiver : spy:PID (8,100,183,1) "SIPHandler", Priority : kNormalPriority) at ProcessSIPHandler.cpp:1683 #13 0x09e69c7b in SdlProcessBase::inputSignal (this=this@entry=0xac1c05e8, rSignal=rSignal@entry=0x7d2f8a78, traceType=SdlSystemLog::SignalThreadedWithPriorities, highPriority=0, normalPriority=0, lowPriority=0, veryLowPriority=0, lazyPriority=0, dbUpdatePriority=0) at SdlProcessBase.cpp:417 #14 0x09e8d2fd in SdlThreadedProcess::threadQueueReader (this=this@entry=0xac1c05e8) at SdlThreadedProcess.cpp:110 #15 0x09e8d56d in SdlThreadedProcess::threadQueueReaderInit (sdlThreadedProcess=0xac1c05e8) at SdlThreadedProcess.cpp:75 #16 0xf69beb3c in start_thread () from /usr/lib/libpthread.so.0 #17 0xf687f44e in clone () from /usr/lib/libc.so.6 BOth the threads are allocated memory at the same time , eventually resulting in deadlock. -Thanks

1 0

Last minute speaker needed for FOSDEM Dojo
by Rich Bowen 24 Jan '19

24 Jan '19

Hello, friends, One of the scheduled speakers for the FOSDEM Dojo has had to withdraw at the last minute due to a medical emergency. If you will be in Brussels next Friday, and are willing to present on a CentOS-related topic, please contact me off-list with a proposed title and abstract, by end of business tomorrow. Please see https://wiki.centos.org/Events/Dojo/Brussels2019 for an idea of what kind of talks we already have scheduled. Thank you! -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

1 0

AMI images on AWS
by Rich Bowen 23 Jan '19

23 Jan '19

I asked this on IRC, but posting it here, too, in case someone sees it here and not there. Can someone volunteer to respond to this tweet: https://twitter.com/translatewiki/status/1088137687461183488 "@CentOSProject Can you point me to an active contributor to cloud images in the community? I've searched before, and failed, and the CentOS @awscloud AMIs haven't been updated since May 2018 (i.e. are still on 7.5). https://aws.amazon.com/marketplace/pp/B00O7WM7QW " I have no idea how those are updated, or who provided what's there. I seem to remember asking this before, but I don't think anybody raised their hands. If you know, or if it's you, please document here - https://wiki.centos.org/Cloud/AWS - how one goes about uploading those images, and/or who is responsible for doing so. -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

1 1

Adding to the PPC arch group
by Philip Prindeville 22 Jan '19

22 Jan '19

Hi. I and my development group are interested in doing ppc (ppc32) development for CentOS 7 and getting that running on certain SoC-based platforms. I imagine that there’s some overlap with the 32-bit component on the Power7 work. We have Centos 7.6 x86_64 servers that we can do in-house builds on. We’re mostly looking for collaboration, and maybe a little initial guidance about the pitfalls of setting up a cross build environment, adapting RPM .spec's for additional architectural builds, etc. We have no idea how much work this will be. We’re also interested in supporting newer (4.10 or later) kernels, so we’ll probably contribute to elrepo as well. Any pointers/wisdom welcome. Thanks, -Philip

2 1

what about CentOS7 ppc64 ?
by Fabian Arrotin 22 Jan '19

22 Jan '19

Just wondering the status of CentOS 7 ppc64, as 7.6.1810 was released on December 3rd 2018 for all arches *but* ppc64, and no news since. In the CentOS Infra, I had to maintain ppc64 hosts for both cbs/koji and other nodes, but as recently, someone decided to archive 7.5.1804 to vault, and also that there is no ppc64 anymore on mirrors, one having to deal with ppc64 is now in a position where : - it's impossible to install new ppc64 host - it's impossible to just "yum install" anything either Can we get an official statement from the ppc64 maintainer about this ? Or should we consider that arch dead and unmaintained, and if so, I can remove ppc64 from the centos infra too ... (or maybe we should find a new maintainer, etc ..) Anyway, any official statement would be good at this stage. Cheers, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

2 1

DevConf.CZ RDO Booth Call For Volunteers and Demos!
by Rain Leander 22 Jan '19

22 Jan '19

Hello one and all! We are gearing up for DevConf.CZ <https://devconf.info/cz>where we'll have our regular booth presence. We'll continue the ManageIQ / RDO demo we started last year and we'd love to see your demos, too! If you've got something you'd like to demo via video OR LIVE because you're not afraid of ANYTHING, please sign up! <https://etherpad.openstack.org/p/devconfCZ-2019-booth> We're also looking for people to spend their precious free time answering questions at the RDO booth. If you're attending, please consider spending one or more of your free moments with us. Questions run the gamut from "What's RDO?" to "I found a bug in Neutron and need help troubleshooting it." Of course, you're not expected to know everything and you can always keep IRC open to access the RDO Community for help! Plus, you get cool stuff! If you show up for three or more shifts, we're going to hook you up with an RDO hoodie. See you soon! -- K Rain Leander OpenStack Community Liaison Open Source and Standards Team https://www.rdoproject.org/ http://community.redhat.com

1 0

CentOS support of s390x architecture
by Vaibhav Kaushik 19 Jan '19

19 Jan '19

Hello everyone, I want to help in building the official centOS support of s390x architecture for Open Mainframe Project. I have familiarity with Linux and working with build systems. The task is to "Bootstrap CentOS on Z" and I need some guidance and reference about where to begin so that I can start learning and contributing. -- Regards, Vaibhav Kaushik (vaibhavk.github.io)

1 0

centos-logos package not updated on git.centos.org
by Maheshwari, Shagun 18 Jan '19

18 Jan '19

Hi, I am using git.centos.org site for source code but don't see the latest commit of centos-logos package on git.centos.org. And, at vault.centos.org centos-logos-70.0.6-3.el7 version is available which is latest, could anyone please check. Version on git.centos.org site: 70.0.6-2 Version on vault.centos.org site: 70.0.6-3 Regards, Shagun

1 0

Vagrant centos/7 v1811.01 breaks nfs at boot
by John-Paul Robinson 16 Jan '19

16 Jan '19

Hi folks, It seems that the latest vagrant box for centos/7 is breaking nfs mounts at boot. My vagrant project has an nfs server and client node. The client has two nfs mount in fstab. https://gitlab.rc.uab.edu/jpr/ohpc_vagrant Using the image from the prior release (1804.02, kernel 3.10.0-862.2.3.el7.x86_64, CentOS Linux release 7.5.1804 (Core) ) the mounts complete successfully. The newest releases (1811.02 and 1809.01) fail to mount the drives at boot. I believe the differences between the older VMs using XFS and volume manager vs direct device and ext4 in the newer images are changing the boot timings of services. The messages.log shows that the network is unavailable at the point which the nfs mounts are tried on the failing nodes. The wait service doesn't appear to work right or wait long enough to allow the network to come up first. It seems that the boot for the direct use of the sda1 and use of ext4 simply initializes too fast. Here's the top of the systemd blame info for the box that succeeds in it's nfs mounts at boot (v1804.02). Note that the boot times are dominated by the network manager wait service: [vagrant@ood ~]$ systemd-analyze blame 2.970s NetworkManager-wait-online.service 1.511s tuned.service 1.272s postfix.service 594ms httpd24-httpd.service 538ms lvm2-monitor.service 474ms opt-ohpc-pub.mount 471ms home.mount 450ms auditd.service 444ms dev-mapper-VolGroup00\x2dLogVol00.device 380ms boot.mount 343ms network.service 216ms munge.service 206ms NetworkManager.service 177ms chronyd.service 157ms polkit.service 149ms sshd.service 148ms systemd-logind.service 134ms slurmd.service 114ms gssproxy.service 112ms lvm2-pvscan@8:3.service 112ms rpc-statd.service 112ms systemd-udev-trigger.service 111ms rsyslog.service 110ms rhel-readonly.service 105ms rhel-dmesg.service 91ms systemd-vconsole-setup.service 84ms systemd-tmpfiles-setup-dev.service 74ms systemd-tmpfiles-clean.service 72ms dev-mapper-VolGroup00\x2dLogVol01.swap 66ms kmod-static-nodes.service 65ms rhel-domainname.service 65ms rpc-statd-notify.service ... Here's the top of systemd blame info for the box that is failing to mount nfs (v1811.02), network manager barely waits: [vagrant@ood ~]$ systemd-analyze blame 1.811s dev-sda1.device 1.737s tuned.service 1.594s postfix.service 785ms httpd24-httpd.service 378ms systemd-vconsole-setup.service 295ms slurmd.service 291ms network.service 286ms home.mount 266ms auditd.service 253ms opt-ohpc-pub.mount 250ms NetworkManager-wait-online.service 208ms systemd-udev-trigger.service 200ms polkit.service 188ms systemd-tmpfiles-setup-dev.service 180ms sshd.service 177ms chronyd.service 175ms rhel-readonly.service 146ms rhel-dmesg.service 145ms munge.service 144ms gssproxy.service 141ms rpcbind.service 139ms swapfile.swap 112ms rhel-domainname.service 102ms systemd-udevd.service 101ms systemd-journald.service 91ms rpc-statd.service 78ms rsyslog.service 70ms var-lib-nfs-rpc_pipefs.mount 69ms systemd-tmpfiles-setup.service 61ms rpc-statd-notify.service 58ms systemd-journal-flush.service 58ms systemd-sysctl.service ... I have the boot svd graphs that tell a similar story on the sequencing of service startup. Is there a way to add delay to the network manager wait or otherwise influence the boot configuration to ensure the NFS drives mount correctly at boot? Thanks, John-Paul

3 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel