Menu
▾
▴
[Bacula-bugs] [bacula 0000326]: Bad PSCMD commands in configure for BSD systems
|
From: <bac...@li...> - 2005-05-26 06:28:29
|
The following bug has been CLOSED ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000326 ====================================================================== Reported By: Rudolf Cejka Assigned To: ====================================================================== Project: bacula Bug ID: 326 Category: configure/build process Reproducibility: always Severity: minor Priority: normal Status: closed ====================================================================== Date Submitted: 05-23-2005 06:27 PDT Last Modified: 05-25-2005 23:28 PDT ====================================================================== Summary: Bad PSCMD commands in configure for BSD systems Description: If you want to see full process list under BSD systems, you have to use "ps -ax", not just "ps -a" or "ps -x" as is currently used in configure script for bsdi/netbsd/freebsd (just openbsd is correct). ====================================================================== ---------------------------------------------------------------------- kern - 05-23-2005 11:41 PDT ---------------------------------------------------------------------- What is the bug? You have not explained the problem. That ps command is a sort of last resort for killing a Bacula process and to the best of my knowledge works just fine. You will have to explain why it does not work before going any further. Also, please note, the patch must be applied against autoconf/configure.in -- configure is a generated file. ---------------------------------------------------------------------- Rudolf Cejka - 05-25-2005 01:08 PDT ---------------------------------------------------------------------- > What is the bug? You have not explained the problem. For example FreeBSD, bacula 1.36.3, and daemons are running as Director: bacula:bacula Storage Daemon: bacula:operator File Daemon: root:wheel $ bacula status # run as bacula user bacula-sd (pid 19599) is running... # under the same user bacula-fd dead but pid file exists # under different user - bad bacula-dir (pid 19604) is running... # under the same user # bacula status # run as root user bacula-sd dead but pid file exists # under different user - bad bacula-fd (pid 65422) is running... # under the same user bacula-dir dead but pid file exists # under different user - bad It is because just ps -x is used on FreeBSD and -a is missing, which means that ps lists just processes owned by the user, who runs ps. The correct ps -ax is used just for OpenBSD, but not for FreeBSD, NetBSD, nor BSDI. $ bacula.fixed status # as bacula or root, ps -ax bacula-sd (pid 19599) is running... bacula-fd (pid 65422) is running... bacula-dir (pid 19604) is running... > That ps command is a > sort of last resort for killing a Bacula process and to the best of my > knowledge works just fine. Maybe for killing, but not for the status. You search just for "pidof" in configure for direct pid findings. I know about "pidof" just on Linux, but not on FreeBSD nor Solaris (there is "pgrep" instead of "pidof"), so ps is used. I would like to use PIDOF=/usr/bin/pgrep # accepts process-name or PIDOF="/usr/bin/pgrep -f" # accepts /path-to-file/executable but the second case could not work, because tests like if [ -x ${PIDOF} ] ; then ... are used in bacula script. Furthermore, killproc() -> pidofproc() calls pidof just with process-name and status() calls pidof with full /path-to-file/executable, so there may work just killproc() or status() for the first or the second case, but not both without further patching. > You will have to explain why it does not work > before going any further. I'm sorry, I thought it was clear - I hope that now it is better... > Also, please note, the patch must be applied > against autoconf/configure.in -- configure is a generated file. Ok, I have uploaded patch-configure.in for bacula-1.36.3 (I had to return to 1.36.3 in a time, because I'm unable to run 1.37.18 on my system and I even could not properly debug the problem - like some mysterious memory overwrite is somewhere done, but it is for another bug/discussion). ---------------------------------------------------------------------- kern - 05-25-2005 23:27 PDT ---------------------------------------------------------------------- OK, I see your point. Your patch is applied to 1.37.19 (26May05). Thanks. Bug History Date Modified Username Field Change ====================================================================== 05-23-05 06:27 Rudolf Cejka New Bug 05-23-05 06:27 Rudolf Cejka File Added: patch-configure 05-23-05 11:41 kern Bugnote Added: 0000925 05-23-05 11:41 kern Status new => feedback 05-25-05 01:00 Rudolf Cejka File Added: patch-configure.in 05-25-05 01:08 Rudolf Cejka Bugnote Added: 0000932 05-25-05 23:27 kern Bugnote Added: 0000940 05-25-05 23:28 kern Resolution open => fixed 05-25-05 23:28 kern Status feedback => closed ====================================================================== |