ulatencyd shoud be able dynamically link to procps library

[gajdusek]

This bug tracks issues with inability to dynamic link to (unpatched) procps library.

Embedded copy of procps was removed as fix of issue #37 (commit b30c5ef). Unfortunately ulatencyd must still be statically linked to external procps library or procps must be patched to export all needed symbols. Missing symbols are detected and printed in cmake run (in master branch) so you may turn on dynamic linkage to procps (e.g. cmake -D PROCPS_STATIC:BOOL=OFF .) to see what is missing.

FAQ:
Currently dynamic linking to libprocps is mostly useless for most use cases.

Why?

Short answer: missing symbols and unstable API. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685962

From Debian README for libproc-dev

It is generally a bad idea to dynamically link to libproc. The API changes
a fair bit and I cannot guarantee that it will stay the same between minor
versions (though it will stay the same between Debian versions). I've now
re-included the libproc.a file so use that.

libprocps 3.3.9 (in Debian) still missing symbols (not sure if the list is complete):

group_from_gid

kb_inact_laundry, kb_inact_dirty, kb_inact_clean, kb_inact_target, kb_swap_cached,
kb_writeback, kb_slabkb_committed_as, kb_dirty, kb_mapped, kb_pagetables

vminfo, vm_nr_dirty, vm_nr_writeback, vm_nr_pagecache, vm_nr_page_table_pages, vm_nr_reverse_maps, vm_nr_mapped, vm_nr_slab, vm_pgpgin, vm_pgpgout, vm_pswpin, vm_pswpout, vm_pgalloc, vm_pgfree, vm_pgactivate, vm_pgdeactivate, vm_pgfault, vm_pgmajfault, vm_pgscan, vm_pgrefill, vm_pgsteal, vm_kswapd_steal, vm_pageoutrun, vm_allocstall

Therefore, I think GNU/Linux distributions should provide package containing statically built procps library until the procps will be fixed (standardized API and reasonable set of exported symbols). I guess this will not happen soon because, if I know, currently the API holds status quo until (slowly) rewritten and sanitized.

[gajdusek]

@Hubbitus post from closed issue #37:

What about procps-ng?
And there no -static package in Fedora
$ repoquery 'procps'
procps-ng-0:3.3.8-15.fc20.i686
procps-ng-0:3.3.8-15.fc20.x86_64
procps-ng-devel-0:3.3.8-15.fc20.i686
procps-ng-devel-0:3.3.8-15.fc20.x86_64

Every procps with version >= 3.2.9 is actually the procps-ng, which is Debian, Fedora and openSUSE fork of old procps (https://gitorious.org/procps). The old procps (<= 3.2.8) from http://procps.sourceforge.net/ does not work with ulatencyd. But I think this was embedded (and heavily patched) in ulatencyd before I removed it. It was making the ulatencyd code complicated and buggy, and introducing memory leaks. IIRC, the old procps will certainly not work with current ulatency code (and the cmake will detect it and fail).

I think nearly every distribution released in 2012+ uses procps-ng. The problem is procps-ng being very slowly rewritten (in sense of being cleaned and fixed) and upstream plans to the future are rewrite and sanitize its API; and in my feeling until this is not finished, requests to export more symbols won't be accepted.

Currently exported symbols seems like incoherent random set of mess. Some kb_* variables exported, some not. user_from_uid() exported, group_from_uid() not. procps-ng 3.3.3 didn't have even mandatory freeproc(): IIRC no way to release allocated memory if dynamically linked! And Debian stable still has 3.3.3.

So we may wait for (or help) procps-ng cleaning process, or patch it and take care about API (i.e. fork!), or embed it again in to ulatency source tree or, finally, statically link to the procps (or procps-ng) provided by distribution.

I think the static linking is the only way we can go; beside the way of helping the procps-ng upstream, of course. Static linking to the library provided by a distribution is from the security view much better than library embedded into ulatencyd source tree. But this causes problems to you because Fedora does not have propc-ng-static package. Would you mind to fill report in Fedora buglist? I think it is justified as currently the static linking is only suitable (and secure) way how to use procps-ng library.

Otherwise what can I do?

1. Embed procps-ng inside ulatency. This is much worse from nearly all views (security, maintanace, licences etc.).
2. Do not use procps and write the needed code from scratch

[PaddyMac]

There is a mention of the possibility of patching procps to export more symbols. Do you have a patch which achieves this?

[mailinglists35]

i'm getting these errors on ubuntu xenial. how do i fix it?
ii libprocps4-dev:amd64 2:3.3.10-4ubuntu2 amd64 library for accessing process information from /proc

procps.txt