Stefan Seefeld | 25 Oct 22:56 2014

bug reporting link(s) on new website

Hello,

Looking for the bug trackers for lttng-ust and lttng-tools, I notice
https://bugs.lttng.org/, which looks rather incomplete. Is there a
reason it doesn't link the lttng-ust and ltng-tools trackers
(https://bugs.lttng.org/projects/lttng-ust and
https://bugs.lttng.org/projects/lttng-tools) ?

Thanks,
        Stefan

--

-- 
Stefan Seefeld
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software/
Mathieu Desnoyers | 25 Oct 14:51 2014

Progress on system crash traces with LTTng using DAX and pmem

Hi Matthew, Hi Ross,

A quick follow up on my progress on using DAX and pmem with
LTTng. I've been able to successfully gather a user-space
trace into buffers mmap'd into an ext4 filesystem within
a pmem block device mounted with -o dax to bypass the page
cache. After a soft reboot, I'm able to mount the partition
again, and gather the very last data collected in the buffers
by the applications. I created a "lttng-crash" program that
extracts data from those buffers and converts the content
into a readable Common Trace Format trace. So I guess
you have a use-case for your patchsets on commodity hardware
right there. :)

I've been asked by my customers if DAX would work well with
mtd-ram, which they are using. To you foresee any roadblock
with this approach ?

FYI, the main reason why my customer wants to go with a
"trace into memory that survives soft reboot" approach
rather than to use things like kexec/kdump is that they
care about the amount of time it takes to reboot their
machines. They want a solution where they can extract the
detailed crash data after reboot, after the machine is
back online, rather than requiring a few minutes of offline
time to extract the crash details.

So I guess next year I'll probably be looking into
allocating the LTTng kernel tracer buffers into an mmap'd file
within a ext2/4-DAX-over-pmem/mtd-ram filesystem. It's going
(Continue reading)

David Goulet | 23 Oct 18:01 2014

A kind of farewell :)

Greetings everyone!

This email is to announce that I will be leaving EfficiOS Inc. on
November 1st 2014 thus *not* working full time anymore on the LTTng
project.

<dreamy paragraph>

I've been involved for 5 years in the project of which 4 years
maintaining the lttng-tools code base so rest assure it's with some
sadness that I'm leaving. I'll be tackling new challenges that hopefully
will include a LTTng component :).

</dreamy paragraph>

For now, I will still act as the maintainer but a transition has
started. Jérémie Galarneau (jgalar) will be co-maintainer until he feels
confident to take on the responsabilities alone :). Now the only one
question remains, is Jérémie up to the challenge?! :P

In all seriousness, it's a blast to work on LTTng and rest assure, I
will still be around the LTTng community for a long time!

Thanks to everyone that I had the chance to work and collaborate with,
it has been an immense pleasure for me. I will certainly miss your well
(NOT) formatted patches and one liner bug reports! :P

Remember, LTTng all comes down to this debug output that I added 4 years
ago (and that segfault also on me... :):

(Continue reading)

Anette Schött | 23 Oct 09:10 2014
Picon

network namespace and LTTng

Hi,

 

I have a question regarding network namespace and LTTng ’live streaming’.

 

Can you see any problems to have a user application using UST tracing in one network namespace and the lttng-sessiond daemon executing in another namespace?

 

Regards

Anette

_______________________________________________
lttng-dev mailing list
lttng-dev <at> lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Anand Neeli | 23 Oct 09:07 2014
Picon

health check and relaunch of lttng daemons

Hi All,
I have few queries related to notifications when lttng daemons die and their spawning and health-check

- When relayd dies then sessiond gets error of connection reset, but it doesnt try to reconnect to relayd again. It just lies on system without being functional.

- on a system with multiple nodes, relayd can be spawned on any node. Is there a way for the sessiond to discover or get relayd IP-address. (Again in case relayd dies and gets spawned on different node, then sessiond has to discover and re-connect)

- How is the health_check used. Is it deprecated? coz in lttng.h i see
extern LTTNG_DEPRECATED("This call is now obsolete.")
int lttng_health_check(enum lttng_health_component c);

If health_check can be used for relayd and sessiond?
Can anyone provide more pointers or example code for health check?


- it becomes really important to get notification/signal from relayd, so that software can be added to respawn sessiond. 
please let me know if there is anyway of doing this.


Thanks,
Anand Neeli




On Tue, Oct 21, 2014 at 12:10 AM, Anand Neeli <anand.neeli <at> gmail.com> wrote:
one more point:
if there is a way to kill/exit sessiond on a connection reset then will be easier to re-launch it again

wondering if anything of that sort can be done

Thanks,
Anand Neeli

On Tue, Oct 21, 2014 at 12:02 AM, Anand Neeli <anand.neeli <at> gmail.com> wrote:
Hi All,
if relayd gets killed i see there is connection reset which happens at client.
Is there a way to relaunch the sessiond/consumerd on a connection reset?

can some hooks be added or helper application be written to relaunch sessiond in case exit of relayd or any other connection reset?

Thanks,
Anand Neeli


_______________________________________________
lttng-dev mailing list
lttng-dev <at> lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Boisvert, Sebastien | 22 Oct 22:34 2014

Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

I am using LTTng-UST (lttng 2.4.1-1.el6) and babeltrace (1.2.1-1.el6) on CentOS 6.5 (using EPEL).

I have 2 hexadecimal fields:

      ctf_integer_hex(int, script, actor->script->identifier)
      ctf_integer_hex(int, action, message->action)

One of them is printed with leading Fs (64 bits) while the other is fine (32 bits), but both should be 32 bits wide.

[14:52:27.416502837] (+0.000005124) silverclaw.novalocal thorium_actor:receive_exit: { cpu_id = 6
}, { name = 1000452, script = 0xFFFFFFFFEB3B39FD, action = 0x7724, count = 41 }

I expect "script = 0xEB3B39FD" and not script = 0xFFFFFFFFEB3B39FD since this is a int (sizeof(int) is 4).

Am I doing something wrong ?
Mathieu Desnoyers | 21 Oct 21:07 2014

[RELEASE] Userspace RCU 0.8.5

liburcu is a LGPLv2.1 userspace RCU (read-copy-update) library. This
data synchronization library provides read-side access which scales
linearly with the number of cores. It does so by allowing multiples
copies of a given data structure to live at the same time, and by
monitoring the data structure accesses to detect grace periods after
which memory reclamation is possible.

liburcu-cds provides efficient data structures based on RCU and
lock-free algorithms. Those structures include hash tables, queues,
stacks, and doubly-linked lists.

This is a bugfix release.

Changelog:
2014-10-21 Userspace RCU 0.8.5
        * Fix: preserve example files' timestamps when copying
        * rculfhash: remove duplicated code
        * rculfhash: handle pthread_create failures
        * rculfhash: fall back to single-threaded resize on calloc failure
        * x86: drop extra semi-colon in caa_cpu_relax
        * Fix: Use after free in rcu_barrier()
        * Fix: rcu_barrier(): uninitialized futex field
        * call_rcu threads should clear their PAUSED flag when they unpause
        * Fix: bring back dummy rcu_bp_exit symbol

Project website: http://urcu.so
Git repository: git://git.urcu.so/urcu.git

--

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Mathieu Desnoyers | 21 Oct 21:03 2014

[RELEASE] Userspace RCU 0.7.13

liburcu is a LGPLv2.1 userspace RCU (read-copy-update) library. This
data synchronization library provides read-side access which scales
linearly with the number of cores. It does so by allowing multiples
copies of a given data structure to live at the same time, and by
monitoring the data structure accesses to detect grace periods after
which memory reclamation is possible.

liburcu-cds provides efficient data structures based on RCU and
lock-free algorithms. Those structures include hash tables, queues,
stacks, and doubly-linked lists.

This is a bugfix release.

Changelog:
2014-10-21 Userspace RCU 0.7.13
        * rculfhash: remove duplicated code
        * rculfhash: handle pthread_create failures
        * rculfhash: fall back to single-threaded resize on calloc failure
        * x86: drop extra semi-colon in caa_cpu_relax
        * call_rcu threads should clear their PAUSED flag when they unpause
        * Fix: bring back dummy rcu_bp_exit symbol

Project website: http://urcu.so
Git repository: git://git.urcu.so/urcu.git

--

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
David Goulet | 21 Oct 20:37 2014

[RELEASE] LTTng-Tools 2.6.0-rc2

Greetings everyone (including LTTng bards!),

The lttng-tools project provides a session daemon (lttng-sessiond) that
acts as a tracing registry, the "lttng" command line for tracing
control, a lttng-ctl library for tracing control and a lttng-relayd for
network streaming and live reading.

This is version 2.6.0 release candidate 2. Yes, one day after rc1, we
had to add a kernel version check because of the syscall tracing feature
that extends the kernel ABI.

To be clear, you NEED rc2 to work with lttng-modules rc1.

2014-10-21 lttng-tools 2.6.0-rc2
    * Use lttng-modules ABI version ioctl
	* Fix: syscall list ioctl number conflict

Please report ANY issues to bugs.lttng.org or on that mailing list.

Using it is testing it!

Project website: https://lttng.org
Download link:
https://lttng.org/files/lttng-tools/lttng-tools-2.6.0-rc2.tar.bz2
GPG sig: https://lttng.org/files/lttng-tools/lttng-tools-2.6.0-rc2.tar.bz2.asc

Cheers!
David
_______________________________________________
lttng-dev mailing list
lttng-dev <at> lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Thibault, Daniel | 21 Oct 16:44 2014
Picon

lttngtop dependencies

Currently, the lttngtop/README mentions only the following dependencies:

* gcc 3.2 or better
* libc6 development librairies (Debian : libc6, libc6-dev) (Fedora : glibc, glibc)
* glib 2.22 or better development libraries (Debian : libglib2.0-0, libglib2.0-dev) (Fedora : glib2, glib2-devel)
* libpopt >= 1.13 development libraries (Debian : libpopt-dev) (Fedora : popt)
* ncurses development libraries (Debian : libncurses5-dev)
* babeltrace >= 1.2.0 development library

   However, since 19 October 2013
(http://git.lttng.org/?p=lttngtop.git;a=commitdiff;h=16b22a0fe150f4923b9902e802bbf28bacce8d0e),
lttngtop depends on lttng-tools (for lttng/lttng.h, lttng/lttngtop-helper.h and later headers,
needed to handle live traces).  This must be added to the README (not to mention any DEBIAN/control package files).

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>
Mathieu Desnoyers | 21 Oct 01:14 2014

[RELEASE] LTTng modules 2.6.0-rc1

The LTTng modules provide Linux kernel tracing capability to the LTTng
2.x tracer toolset.

New & noteworthy features in this release:
- System call filtering! Fine-tune which system calls you want
  to trace or not,
- We now gather in/out parameters of system calls at entry and
  exit of the syscall. Please note that the system call event
  semantic (naming) have changed in this release. You may have
  to update your analysis if they depended on the old semantic.
- Trace NMI handlers, using the new NMI-safe clock monotonic
  available in kernels >= 3.17,

Please note that the feature "syscall listing" will need lttng-tools
2.6.0-rc2 (which should come soon). We had to fix an ioctl numbering
clash at the last minute between the tools rc1 and modules rc1
releases.

Changelog:
2014-10-20 LTTng modules 2.6.0-rc1
        * Expose lttng-modules ABI version ioctl
        * Fix: syscall list ioctl number conflict
        * lttng-modules: fix build for non-x86
        * Fix: syscall listing of session
        * Print build warning when writeback probe is disabled
        * Add atomic.h wrapper for before/after atomic
        * Fix compilation on Ubuntu 14.10
        * Fix: export name as text array in writeback
        * Cleanup: remove unused trace_clock_read32()
        * Use 3.17 ktime_get_mono_fast_ns() new API
        * Check for stale version.h files
        * Fix: compile lttng_statedump_process_ns on Ubuntu
        * Reverse version check logic in lttng_statedump_process_ns
        * Fix block_rq_complete TP on Ubuntu kernel
        * Introduce macros to check Ubuntu kernel version
        * Sync writeback tracepoints from mainline
        * Fix: redefinition of DEFINE_WRITEBACK_EVENT
        * Fix: hander negative get_syscall_nr return value
        * Fix: statedump: close_on_exec flag backward compat
        * Fix instrumentation of vmscan for older kernels
        * Fix: older kernels (3.2.x) don't undefine TRACE_SYSTEM
        * Fix: syscall listing: handle "enable all syscall"
        * Fix: don't allow disabling syscalls when none are enabled
        * Fix: syscall: fail disable all if all already disabled
        * Fix: syscall filtering: NULL pointer deref
        * Cleanup: list syscall without syscall_entry prefix
        * Fix: syscall_list_show NULL pointer deref
        * implement syscall mask getter
        * Cleanup: lttng-abi.h coding style
        * syscall listing: show syscall ID
        * Allow events with same name to be enabled for each channel
        * ABI: use enable a syscall ABI field name
        * Implement syscall listing
        * Fix: tracepoint list anonymous file name
        * Fix: syscall filtering: disable all syscalls
        * syscall tracing: input/output parameter handling for all arch
        * lttng-get-syscall-inout.sh depends on bash
        * Fix generate syscall header script: add missing escape char
        * syscall instrumentation: handle copy_from_user return value
        * Rename LTTng syscall instrumentation macros
        * Rename LTTng instrumentation macros
        * Extract input/output arguments from accept and connect syscalls
        * syscall: extract pipe and pipe2 output args
        * Remove sys_ prefix from syscall names
        * System call inout/output arg processing
        * Update syscall inout table
        * Add syscall inout table
        * Extract syscall exit ret value on x86 32/64
        * Extract system call exit return value
        * Syscall filtering: apply to syscall exit
        * System call filtering
        * asoc.h: fix build with v3.17 kernel
        * Fix: lttng-modules teardown NULL pointer OOPS
        * Fix: handle concurrent flush vs get_next_subbuf on metadata cache
        * Modernize README using Markdown
        * Fix: OOT lttng_logger tracepoint not visible with signed kernels
        * Add cscope to gitignore
        * Update kvm instrumentation: compile on 3.17-rc1
        * Update statedump to 3.17 nsproxy locking
        * Fix: noargs probes should calculate alignment and event length
        * Update compaction instrumentation to 3.16 kernel
        * Update vmscan instrumentation to 3.16 kernel

Project website: http://lttng.org
Download link: http://lttng.org/download
(please refer to the README.md files for installation instructions and
lttng-tools doc/quickstart.txt for usage information)

--

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Gmane