search for: sysv

Hello, sorry for my later answer. so, after i started libvirtd (no vm´s running) and attach gdb i get the following threads (gdb) info thread Id Target Id Frame 11 Thread 0x7f18fef4e700 (LWP 20695) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 10 Thread 0x7f18fe74d700 (LWP 20696) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 9 Thread 0x7f18fdf4c700 (LWP 20697) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/...

...i started libvirtd (no vm´s running) and attach gdb i get the >> following threads >> >> (gdb) info thread >> Id Target Id Frame >> 11 Thread 0x7f18fef4e700 (LWP 20695) "libvirtd" >> pthread_cond_wait@@GLIBC_2.3.2 () at >> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> 10 Thread 0x7f18fe74d700 (LWP 20696) "libvirtd" >> pthread_cond_wait@@GLIBC_2.3.2 () at >> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> 9 Thread 0x7f18fdf4c700 (LWP 20697) "libvirtd" >>...

Hi Michal, thank you for your answer. so if i understand that correctly, no matter if i shutdown or destroy the domain and no matter if it is a transient or an persistent vm, the thread should disappear, right? in my case they still exist, also an hour after i destroy the domain (and don´t start any new one). i use libvirt-1.1.35 on fedora core 20, for information. all the best max    

...y for my later answer. > > so, after i started libvirtd (no vm´s running) and attach gdb i get the following threads > > (gdb) info thread > Id Target Id Frame > 11 Thread 0x7f18fef4e700 (LWP 20695) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > 10 Thread 0x7f18fe74d700 (LWP 20696) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > 9 Thread 0x7f18fdf4c700 (LWP 20697) "libvirtd" pthread_cond_wait@@GLIBC_2.3.2 ()...

...running) and attach gdb i get the >>> following threads >>> >>> (gdb) info thread >>> Id Target Id Frame >>> 11 Thread 0x7f18fef4e700 (LWP 20695) "libvirtd" >>> pthread_cond_wait@@GLIBC_2.3.2 () at >>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >>> 10 Thread 0x7f18fe74d700 (LWP 20696) "libvirtd" >>> pthread_cond_wait@@GLIBC_2.3.2 () at >>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >>> 9 Thread 0x7f18fdf4c700 (LWP 20697) "libvirtd...

...LLIN|POLLERR|POLLHUP}, {fd=50, >> events=POLLIN|POLLERR|POLLHUP}, ...], 43, 5000 >> >> # gdb -p 5786 >> (gdb) thread apply all bt >> >> Thread 17 (Thread 0x7f411a9d7700 (LWP 5788)): >> #0 pthread_cond_wait@@GLIBC_2.3.2 () at >> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> #1 0x00007f4129c2a2e6 in virCondWait (c=c@entry=0x7f412b18ebb8, >> m=m@entry=0x7f412b18eb90) at util/virthread.c:154 >> #2 0x00007f4129c2ada3 in virThreadPoolWorker >> (opaque=opaque@entry=0x7f412b183ab0) at util/virthreadpool.c:124...

...ux-gnu/libthread_db.so.1". 0x00007fcf4c75f67d in poll () at ../sysdeps/unix/syscall-template.S:84 84../sysdeps/unix/syscall-template.S: (no such file or directory)没有那个文件或目录. "" Thread 18 (Thread 0x7fcf3a4e8700 (LWP 14799)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007fcf4e17ee36 in virCondWait (c=c@entry=0x7fcf3400cc90, m=m@entry=0x7fcf3400cc50) at util/virthread.c:154 #2 0x00007fcf405498a0 in udevEventHandleThread (opaque=<optimized out>) at node_device/node_device_udev.c:1606 #3 0x00007fcf4e17ec0...

On Tue, Dec 29, 2015 at 5:23 PM, Joseph L. Casale <jcasale at activenetwerx.com > wrote: > Instead of converting the sysv script, you could trivially write your own, > the following > was tested against about 6 SNMP queries, the service stops and starts as > expected. > That's certainly an option. One that I was prepared to resort to. But curiosity has the best of me ... I would like to know why the S...

Hello CentOS List, I have a server that has SysV script supplied by a hardware manufacturer, which is not functioning properly. From my reading, systemd-sysv-generator should handle them (like it did for Dell OpenManage software which supplied SysV init scripts). /usr/lib/systemd/system-generators/systemd-sysv-generator Takes no or 3 arguments (...

...no crash, noting in "dmesg" or "xl dmesg". When i attached to the libvirtd via gdb and do a "info thread", i get the following: Id Target Id Frame 21 Thread 0x7f792a92c700 (LWP 1312) "libvirtd" __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 20 Thread 0x7f792a12b700 (LWP 1313) "libvirtd" __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 19 Thread 0x7f792992a700 (LWP 1314) "libvirtd" __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowl...

....5 #6 0x00007f2179a8c5f3 in QThread::exec() () from /lib64/libQt5Core.so.5 #7 0x00007f2179a909da in QThreadPrivate::start(void*) () from /lib64/libQt5Core.so.5 #8 0x00007f2170ccd6ca in start_thread (arg=0x7f2019fa1700) at pthread_create.c:333 #9 0x00007f2178e83f6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 39 (Thread 0x7f201a7a2700 (LWP 7129)): #0 0x00007ffdf5680b12 in clock_gettime () #1 0x00007f2178e92686 in __GI___clock_gettime (clock_id=1, tp=0x7f201a7a19d0) at ../sysdeps/unix/clock_gettime.c:115 #2 0x00007f2179b27af1 in qt_gettime() () from /lib64/libQt5Core.s...

...I've gathered below, I don't think this is relative to needing x86 libraries. ( Has Red Hat even built x86 libraries for x86_64 since RHEL7 no longer supports x86? ) ~]# file /etc/lsi_mrdsnmp/lsi_mrdsnmpagent /etc/lsi_mrdsnmp/lsi_mrdsnmpagent: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.0, not stripped ~]# ldd /etc/lsi_mrdsnmp/lsi_mrdsnmpagent linux-vdso.so.1 => (0x00007ffd29f4a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fccadc7c000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fccad974000) libm.so.6 => /...

Hi all, when I check for updates with yum, it gives me a list of packages, with some additional info, e.g. --> systemd-sysv-219-42.el7_4.1.x86_64 from @updates removed (updateinfo) --> systemd-sysv-219-42.el7_4.4.x86_64 from updates removed (updateinfo) yum info will tell me that I have 4.1 of this package installed, and that 4.4 is available - from the repo updates. What is the meaning of the "@" - i...

...or a better explanation of this: /ADT/APInt.h:1217: uint64_t llvm::APInt::getZExtValue() const: Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed. Program received signal SIGABRT, Aborted. 0x00007ffff6eb4d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) bt #0 0x00007ffff6eb4d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff6eb8ab6 in abort () at abort.c:92 #2 0x00007ffff6e...

...with postgresql 8.1.3 on a new Intel OS X box? All hints welcome, please! I installed postgres 8.1.3 via darwinports, and everything is great until the initdb step. Initdb fails on shmget saying it couldn''t allocate enough memory (see below). So, I edited /etc/rc and increased kern.sysv.shmmax from 4194304 to 41943040 (4MB to 40MB) After reboot and attempt to initdb, I get the same error. Thanks, John jdell@xyz->sudo su postgres8 -c ''/opt/local/lib/pgsql8/bin/initdb -D /opt/local/var/db/pgsql8/postgres8'' Password: The files belonging to this database syst...

On 12/29/2015 10:13 AM, Mike - st257 wrote: > Hello CentOS List, > > I have a server that has SysV script supplied by a hardware manufacturer, > which is not functioning properly. From my reading, systemd-sysv-generator > should handle them (like it did for Dell OpenManage software which supplied > SysV init scripts). > > /usr/lib/systemd/system-generators/systemd-sysv-generator &...

...at gmail.com> wrote: > On 30 Dec 2015 00:55, "Mike - st257" <silvertip257 at gmail.com> wrote: > > > > On Tue, Dec 29, 2015 at 5:23 PM, Joseph L. Casale < > jcasale at activenetwerx.com > > > wrote: > > > > > Instead of converting the sysv script, you could trivially write your > own, > > > the following > > > was tested against about 6 SNMP queries, the service stops and starts > as > > > expected. > > > > > > > That's certainly an option. > > One that I was prepared to...

I got curious how the lld produced gnu hash tables compared to gold. To test that I timed "perf record ninja check-llvm" (just the lit run) in a BUILD_SHARED_LIBS build. The performance was almost identical, so I decided to try sysv versus gnu (both produced by lld). The results are interesting: % grep -v '^#' perf-gnu/perf.report-by-dso-sym | head 38.77% ld-2.24.so [.] do_lookup_x 8.08% ld-2.24.so [.] strcmp 2.66% ld-2.24.so...

...R|POLLHUP}, {fd=59, events=POLLIN|POLLERR|POLLHUP}, {fd=46, events=POLLIN|POLLERR|POLLHUP}, {fd=50, events=POLLIN|POLLERR|POLLHUP}, ...], 43, 5000 # gdb -p 5786 (gdb) thread apply all bt Thread 17 (Thread 0x7f411a9d7700 (LWP 5788)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f4129c2a2e6 in virCondWait (c=c@entry=0x7f412b18ebb8, m=m@entry=0x7f412b18eb90) at util/virthread.c:154 #2 0x00007f4129c2ada3 in virThreadPoolWorker (opaque=opaque@entry=0x7f412b183ab0) at util/virthreadpool.c:124 #3 0x00007f4129c2a078 in virThrea...

...ibthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7fe0cbe4d880 (LWP 9602))] Thread 11 (Thread 0x7fdffa0eb700 (LWP 9699)): #0 0x00007fe0c49fd56c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fdff00bca00) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7fdff00bc9b0, cond=0x7fdff00bc9d8) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x7fdff00bc9d8, mutex=0x7fdff00bc9b0) at pthread_cond_wait.c:655 #3 0x00007fe0c585e86b in QWaitCondition::wait(QMutex*, unsigne...