|
I really need some very basic help with Linux.
I am trying to "configure" package and it needs to have access to dependency package "mount".
The "pkg-config" in charge cannot find "mount.pc".
It just does not exists on my OS.
Mrs. Google keeps telling me HOW mount works and is silent about missing "mount.pc".
I do not need to know how mount works, I need to find out why I have no "mount.pc" and most of all - how to fix it.
Any help leading to solution would be appreciated.
Cheers
PS Same posted on "Linux" forum without a result.
|
|
|
|
|
|
Thanks for reply.
I did look at that and its references.
It essentially suggest to build mount.pc.
I did copy what is in references, but I cannot even verify it --exists,
I need to work on that.
Still do not get why mount.pc is missing in first place.
|
|
|
|
|
I am unable to transfer UDP packets with payload length (736) 46 bytes.
The wireshark traces shows BAD UDP payload length( 736) greater than IP payload length (728).
But UDP payload length 736 is less than MTU (1500) so why I am getting this error.
As per my understanding only if the packet length > MTU then it should result in transmission error.
My client program should be sending UDP datagrams for IPv4 protocol.UDP server program is unable to receive UDP messages from the socket. Shouldn't the packet simply be fragmented if the UDP length exceeds the IP Payload Length? IP Payload length max should be MTU value isn't it ?
How to debug this issue further with respect to UDP client and Server?
|
|
|
|
|
Send packets of various lengths and see which ones work and which don't. Then there's pattern from which you can formulate a theory which may lead to a solution. Or not.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
sarali wrote: How to debug this issue further with respect to UDP client and Server?
I used bing/google to search for your Wireshark error code. Amazingly the top 10 results are mostly garbage and incorrect information. Even the response on the wireshark forum was wrong regarding this error message. Welcome to the misinformation age.
Here is an accurate response:
In your case the error message is telling you that the IP header (total packet length - IP header length) is 728. The error message is also telling you that the UDP payload length is 736 which is 8 bytes greater than the IP tot_len value.
It's probably not a coincidence that you are off by 8 bytes... that happens to be the exact length of the UDP header.
Look through your code for the packet length calculation. I am willing to bet you missed adding the UDP header length.
Even if you forced sending this packet over the wire via raw socket... it will be dropped by the receiving side because it's considered corrupt when the packet lengths are mismatched.
TL;DR
You promised to send 728 but sent 736 instead.
Best Wishes,
-David Delaune
|
|
|
|
|
Hi,
I tied to print the packet length calculation in my program before sending it out.
I think the UDP payload length and IP length length calculation looks fine.
APP: INFO: ip header checksum:f9b9 udp checksum size_udp:736 sizeof(struct udp_hdr):8,size_ApplMsg:728udphdr->dgram_len:57346 m->data_len:770 size_ip:756 l2_data_shift:14
Further I am able to transfer UDP packets of size 20bytes,40 bytes using the same program.No issues observed.So right now I do not suspect the program. But I donot understand why the wireshark says "Bad UDP payload length". Not sure how the packet length can go wrong.Whether UDP packet is hardware offloaded ? We may be dropping the packet at the Kernel level due to this bad UDP length. So I tried to increase the UDP buffer size in kernel but of no use.
The netstat -su output shows 0 send/receive buffer errors.
[root@ATCAC06_100 /]# netstat -su
IcmpMsg:
InType0: 233961
InType3: 213187
InType8: 14
OutType0: 14
OutType3: 213187
OutType8: 17
OutType69: 233944
Udp:
592800 packets received
1439 packets to unknown port received.
0 packet receive errors
501661 packets sent
0 receive buffer errors
0 send buffer errors
UdpLite:
IpExt:
In my program I am trying to read the return value of "recvFrom" call is -1 and in that case I tried to print the strerror(errno).
But I could get prints only for the successful case ( return value > 0) and not for unsuccessful case.So mostly the packet is getting dropped at the Kernel level but how do I confirm this.Any debugging steps please share. I am using DPDK 18.08 version( on RHEL 7.6 platform) for packet forwarding.Please suggest how to resolve this issue.
modified 19-Apr-19 14:47pm.
|
|
|
|
|
Listen,
You are posting this same question all over the internet. I've even seen you over on the Intel forums.
My prior analysis is completely correct. Here is the screenshot you posted over on the Intel forums.
https://software.intel.com/sites/default/files/managed/80/b4/bad_udp_length.png
- Your packet length calculation is incorrect.
- Also... your UDP checksum is missing.
The UDP checksum might be OK if you have enabled checksum offloading on your network card. But the packet length calculation is absolutely your problem.
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks David.The issue got resolved it was indeed the packet len which was not getting set correctly.
|
|
|
|
|
sarali wrote: it was indeed the packet len which was not getting set correctly.
I'm happy to have helped.
Best Wishes,
-David Delaune
|
|
|
|
|
I had to write an application long time ago whose job was to check if PID is Active or not.
The Scenario was:
Crontab will execute a process every minute
Process takes longer than a minute
So, new process will check if PID file exists or not
If PID exists new process will abort.
But before aborting new process will ensure that current process is not running longer than 30 minutes. Because, it is observed if the particular process is running more than 20 minutes, it's because some exception that the process couldn't handle. In this case, we simply kill the process for greater good.
Then a scenario crossed my mind.
What if somehow current process failed remove the pid file(whatever the reason) and the PID I am trying to kill is not my my process.
What is the possibility of reaching this scenario.
FYI, I don't handle that service more than 2 years, it's still running. But I want to know if there is any issue.
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
