|
Mohibur Rashid wrote: What is the possibility of reaching this scenario.
I guess if the process segfaults it could potentially leave behind the pid file. Why can't you just cat /proc/YOURPID/exe from your crontab script and check that the path is equal to what you are expecting?
Try it and let me know.
Best Wishes,
-David Delaune
|
|
|
|
|
I have solved the issue readlink command on exe file under pid.
but repeating PID by OS is my concern.
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
Mohibur Rashid wrote: but repeating PID by OS is my concern.
Well I am not a Linux expert but I can read documentation just as good as the next guy. The documentation states /proc/sys/kernel/pid_max defaults to 32786. It also states that the Linux kernel will not reuse a PID until complete wrap-around has occurred.
So if your server is spawning over 32786 processes every 30 minutes... Yes, PID reuse would be an issue for you. Otherwise you are OK.
Best Wishes,
-David Delaune
|
|
|
|
|
As you note, the process could abort without removing the pid file. The man page for ps suggests finding the process name by ps -q <pid> -o comm=. You can then compare the two names, and kill when needed.
Another option would be to use fuser and see if the returned pid, if any, matches that of the pid file.
If you have source code to both the worker process and the controller app, then you could place a lock on the pid file in the worker, and check the lock status in the controller. If no lock has been placed on the pid file, then the worker has died without removing the pid file.
|
|
|
|
|
The issue was solved long time ago, at least 2 years ago and thank you!
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
I am using this link to help me to install a package.
R: Install Add-on Packages[^]
From the documentation I gather I need to have a zipped / tar file.
I downloaded this file "bluez_5.43-2+deb9u1_armhf.deb" and it is not tar file, hence this call fails
im@jim-desktop:~$ R CMD INSTALL bluez_5.43-2+deb9u1_armhf.deb
Warning: invalid package ‘bluez_5.43-2+deb9u1_armhf.deb’
Error: ERROR: no packages specified
Is there another command to install / add package ?
Help will be greatly appreciated.
|
|
|
|
|
I don't know whether to laugh, cry or just shoot myself. Perhaps the best I can do is to quote Wolfgang Pauli: Quote: "That is not only not right; it is not even wrong",
Look, do us all a favor and go out and buy a book on Ubuntu and actually read it.
|
|
|
|
|
I totally agree. I have tried for quite a long time to get this guy to actually learn something about Windows, Linux, compiling, linking, the difference between 32 and 64 bit, all to no avail. My recent attempts to help him just add to my frustration at his lack of understanding of the basics.
|
|
|
|
|
Thank you for that Richard.
For some time I've been thinking that the OP must be some sort of script-kiddie that has managed to install Linux, discovered an IDE and read the first few pages of "C++ for dummies", and now thinks he is on his way to becoming the next Dennis Ritchie. However, this latest query is so egregiously flawed that I've come up with a new theory. It doesn't seem conceivable that any reasonable search query for how to install a .deb file would return a hit for the page given anywhere near the top. That being the case, we must consider that the OP is, in fact, doing this deliberately. Therefore, I can only assume that the OP is some species of troll that is playing some sort of game of "bait the neck-beard". At this point its not unreasonable to assume that getting one of the respondents to announce that they are no longer going to respond accrues major points. If so, I'm going to make someones day by saying I'm not playing any longer. By the way, have you noticed that the OP varies his nickname from "Vaclav_" to "_Vaclav"? Can we thereby assume there's actually 2 of them?
Now if there was only some way to invoke Godwin's law...
|
|
|
|
|
I understand "/../file " means " execute "file " in parent directory, but why is is used in first place ?
In this example I gather the "-L" is linked to "lib" four times.
Do not get it .
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib
Just asking.
|
|
|
|
|
Vaclav_ wrote: In this example I gather the "-L" is linked to "lib" four times.
Do not get it .
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib
No. ../ refers to the parent directory, ../../ refers to the grandparent directory, ../../../ refers to the great-grandparent directory, and ../../../../refers to the great-great-grandparent directory. In this case, you can "walk-back" the final /lib four times so /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib is an alias for /usr/lib. That looks like it comes from the output of gcc -v <source_file>, which means its auto-generated in the process of compiling the compiler. Why its like that and not a 100% absolute path, I don't know. If you're interested on that point, you should query the gcc mailing lists.
In general, in your own compilations, you'll either use an absolute path like -L /usr/local/foo/lib or a relative path like -L ../foo/lib. You'd use the first if you're accessing a 3rd party library in a non-standard place - in this case /usr/local/foo/lib. The second case would normally be when the library is part of the current project.
|
|
|
|
|
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib Should equal
-L/usr/lib/gcc/x86_64-linux-gnu/../../../lib equals
-L/usr/lib/gcc/../../lib equals
-L/usr/lib/../lib equals
-L/usr/lib
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yes, I can see that . the question was - why ?
|
|
|
|
|
You asked:
Vaclav_ wrote: In this example I gather the "-L" is linked to "lib" four times.
Do not get it .
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib
Speaking for myself, the question asked suggests that you think the syntax somehow creates four links to "lib", and are unaware of the relationship between an absolute path and a relative path. Both Eddy Vluggen and I tried to answer the question we thought you had asked, and set you straight about what was going on here.
As I stated in my answer, I think this has come from gcc -v output. As I am not a gcc developer, I do not know why the compiler would generate such odd search paths. It could be something to do with hoops needed to generate correct path names on non unix-like operating systems, like say OpenVMS. The thing to do would be to ask the gcc developers mailing list. As it stands, it works fine, and I'm not aware of any significant performance penalty that accrues from doing things this way. Unless you're interested for interests sake, why worry about it? Essentially, it happens "under the hood" - without the -v option, gcc/g++/as/ld/etc can be considered a "black box" that takes in source code and produces either intermediate code [assembler (.s files) and object (.o files) being two possibilities], or an executable program. How it goes about it is, normally, uninteresting to the average developer. Sometimes, yes, you do need to get that information, particularly if you think you've found a bug and are working with the gcc development team to document the bug. Otherwise, we just loop through the "edit, compile, test" loop until we, or our customer, are happy with the results, not worry about how the compiler, or editor, or link-loader, etc actually do their work.
|
|
|
|
|
The only reason I can come up with, is to ensure that the "gcc/x86_64-linux-gnu/5" folder exists as it would fail if it doesn't.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Paths like that usually come from the config when you build the package on a local machine. Config scripts try to be all things to all people so often create what looks like illogical paths, but are necessary because of the way the scripts analyse a local system.
|
|
|
|
|
Are you saying that it came from the way Eclipse was installed and how IDE relates to the "tool chain"?
I need better understanding of this "install" process.
Especially how piece parts of the "application install " are spread into different Linux folders.
I do not see any point to "hit the books" until I run into issues like this.
Pretty munch tired of not knowing these "under the hood" processes - from the ground up.
This thread answered some of my questions, and I appreciate that.
I think will apply my newly acquired knowledge to get better understanding how Linux "packages" are processed / installed.
Thanks
|
|
|
|
|
See title.
Here is lscpu output on x86.
jim@jim-desktop:~$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 55
Model name: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
Stepping: 3
CPU MHz: 2415.718
CPU max MHz: 2415.7000
CPU min MHz: 1332.8000
BogoMIPS: 3998.40
Virtualization: VT-x
L1d cache: 24K
L1i cache: 32K
L2 cache: 1024K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
Ana here is what armv7l saiz about bits - nothing.
pi@pi:~ $ lscpu
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model: 4
Model name: ARMv7 Processor rev 4 (v7l)
CPU max MHz: 1200.0000
CPU min MHz: 600.0000
BogoMIPS: 38.40
Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
Is this Linux distro depended ? Ubuntu versus Rasbpian?
Just asking.
|
|
|
|
|
The Architecture type x86_64 tells you the hardware is 64 bit Intel architecture. The operating modes tell you it can run 32-bit or 64-bit applications.
|
|
|
|
|
|
I have given up on building bluez library from source.
Now my question is
how to option / instruct (gcc) compiler / linker to use libbluetooth-dev on native OS?
I have downloaded correct version but have no clue how to or where to option the compiler / linker.
I also like to use correct terminology for the "libbluetoooth-dev" .
Is is a libray or package or what ?
When get the above answered I should be able to apply it to different architecture.
I have also run into some kind of "foregin package " options, but not sure I need it. Maybe later.
Help is much appreciated.
Cheers
|
|
|
|
|
What is "libbluetoooth-dev"? Unix/Linux libraries should have a .a (archive) or .so (shared object) extension to identify the type of library. I have explained a number of times that to include a library named libxxx.a or libxxx.so, you should add an option of the form -lxxx to your build (either gcc or ld). If the name of the library does not follow the standard conventions, then use -l:filename.
For all ld opions see ld(1): GNU linker - Linux man page[^].
|
|
|
|
|
Partially answered my own question - libbluetooth-dev is a "package".
Using it / linking to it is non issue.
|
|
|
|
|
I have made some progress in tracing the "configure" script, all the way to
****
@ line 6764 debug START converting (?)
@ line 6765 --build = x86_64-pc-linux-gnu (?)
@ line 6766 --host = armv7l-unknown-linux-gnueabihf (?)
****
checking how to convert x86_64-pc-linux-gnu file names to armv7l-unknown-linux-gnueabihf format... ****
@ line 6831 unhandled host =armv7l-unknown-linux-gnueabihf (and normal native builds) (?)
****
****
@ line 6853 (?)
****
func_convert_file_noop
Now I do not get why "they" are converting build NAME to host FORMAT, but since the triplet "case " switch does not check for anything near "linux" and falls thru to "unhandled " I am beginning to wonder it the source I got from www.bluez.org is for Windowze only.
Is there a away to very that?
I am also stuck as far as what does "func_convert_file_noop" do.
Addendum
Here is a part of "configure" script I believe is responsible in instructing the compiler to build a libray of --host architecture.
As far as I can tell it does not evaluate for "Linux" as OS in optioned triplet , but falls thru to "unhandled" and then the conpiler buidls "native " AKA --build architecture libraries.
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking how to convert $build file names to $host format" >&5
$as_echo_n "checking how to convert $build file names to $host format... " >&6; }
if ${lt_cv_to_host_file_cmd+:} false; then :
$as_echo_n "(cached) " >&6
else
case $host in
*-*-mingw* )
case $build in
*-*-mingw* ) # actually msys
lt_cv_to_host_file_cmd=func_convert_file_msys_to_w32
;;
*-*-cygwin* )
lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32
;;
* ) # otherwise, assume *nix
lt_cv_to_host_file_cmd=func_convert_file_nix_to_w32
;;
esac
;;
*-*-cygwin* )
case $build in
*-*-mingw* ) # actually msys
lt_cv_to_host_file_cmd=func_convert_file_msys_to_cygwin
;;
*-*-cygwin* )
lt_cv_to_host_file_cmd=func_convert_file_noop
;;
* ) # otherwise, assume *nix
lt_cv_to_host_file_cmd=func_convert_file_nix_to_cygwin
;;
esac
;;
* ) # unhandled hosts (and "normal" native builds)
lt_cv_to_host_file_cmd=func_convert_file_noop
;;
esac
fi
to_host_file_cmd=$lt_cv_to_host_file_cmd
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_to_host_file_cmd" >&5
$as_echo "$lt_cv_to_host_file_cmd" >&6; }
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking how to convert $build file names to toolchain format" >&5
$as_echo_n "checking how to convert $build file names to toolchain format... " >&6; }
if ${lt_cv_to_tool_file_cmd+:} false; then :
$as_echo_n "(cached) " >&6
else
#assume ordinary cross tools, or native build.
lt_cv_to_tool_file_cmd=func_convert_file_noop
case $host in
*-*-mingw* )
case $build in
*-*-mingw* ) # actually msys
lt_cv_to_tool_file_cmd=func_convert_file_msys_to_w32
;;
esac
;;
esac
fi
to_tool_file_cmd=$lt_cv_to_tool_file_cmd
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_to_tool_file_cmd" >&5
$as_echo "$lt_cv_to_tool_file_cmd" >&6; }
modified 28-Mar-19 16:24pm.
|
|
|
|
|
1) the configure script is AUTOGENTERATED by the autoconf tool set. There's generally no good that can come from messing about in it.
2) I have told you several times use --host=arm-linux-gnueabihf.
From your post 3 days ago:
Quote: sudo ./configure --prefix=/usr/local/BLUEZ/bluez-5.50 --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var --enable-library --disable-systemd --host=armv7l-unknown-linux-gnueabihf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for armv7l-unknown-linux-gnueabihf-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking how to create a pax tar archive... gnutar
checking for style of include used by make... GNU
checking for armv7l-unknown-linux-gnueabihf-gcc... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
Now, I would expect anyone paying any attention (and surely anyone who's as nit-picky as you seem to be) to think to themselves:
Hmm ... looks like the configure script is trying to use armv7l-unknown-linux-gnueabihf-gcc. That prefix is what I supplied as the value of the --host argument. I don't have arm7l-unkown-linux-gneabihf-gcc on my system. I do have, however arm-linux-gnueabihf-gcc - maybe I'll try --host=arm-linux-gneuabihf and see if that works.
And lo-and-behold configure completes, and you can start make. and wonder of wonders it uses arm-linux-gnueabihf-gcc, just like we want it too. Result!
BUT,BUT, and again BUT: until you've got the prerequisites (GLib, D-Bus) built for armhf make will fail anyway!
3) if you do some googling around for autoconf --target you should find information about the so called candian cross Cross-Compilation (automake). Take the time to read down to the bottom of the page. There it tells you that --target is used when compiling compiler tools i.e. ld, ar, as, etc (binutils) in a three-way cross-compilation. For example, when you are compiling binutils on an X86 to run on an armhf but will produce code for PowerPC. --target has NOTHING to do with cross compiling in the normal way. I have not tried it by suspect that since configure is AUTOGENERATED that the --target option always shows up in the script, whether its required or not.
Now, stop elephanting around.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
