I would like to know if there is a mean to read in a terminal outputs generated by a MicaZ (printf), I tried the command: make login but it doesn't work.
I think that the is no rule login in micaz makefile.
Try command:
sudo cat /dev/ttyUSB1
Before doing this, check that your Micaz is connected through ttyUSB1.
You can check it using command:
ls /dev
If ttyUSB1 is in the list above, it will work.
As far as I remember the MIB510 board, used to program the MicaZ, has two serial ports. One for ISP and the other as a serial console. You might also want to use minicom to be able to fully interact with the serial console. On ubuntu you can install it with sudo apt-get install minicom and is run with minicom -8 -b9600 -D/dev/ttyUSB1 set the baudrate according to your setup.
Here you can find an introduction to minicom.
Good luck!
Related
I am trying to install the macport demeter using the following line in mac terminal:
sudo port install demeter
I get the error message
Error: Failed to activate demeter: Image error: /opt/local/lib/perl5/vendor_perl/5.34/darwin-thread-multi-2level/Ifeffit.pm is being used by the active p5.34-ifeffit port. Please deactivate this port first, or use 'port -f activate demeter' to force the activation.
I have two questions:
(1) Why am I getting this error message? Have I accidentally got two copies of demeter?
(2) How can I deactivate this port? (I'd rather deactivate it then use the force activate option)
When I run
sudo lsof -i -n -P | grep TCP
I can't actually see 'p5.34-ifeffit port' in the list of ports.
This is a bug in the demeter port. It should not install the files of the ifeffit perl module, but instead declare a dependency on p5.34-ifeffit.
Please file a ticket at https://trac.macports.org/newticket.
You can force the activation, but that will overwrite the file(s) in question with the copies from the demeter port. Uninstalling that port later will delete those files, which may then in turn break other software that relies on p5.34-ifeffit.
I'm not experienced with Demeter but you might try asking for help on the MacPorts users mailing list:
https://lists.macports.org/mailman/listinfo/macports-users
Or raise a ticket on the MacPorts Trac system:
https://trac.macports.org/newticket?port=demeter
Craig
I have just installed macports as per the instruction given on their website. But as i type
sudo port install gnuplot
i get an error
Error: Port gnuplot not found
also for self update i get
Error: Error synchronizing MacPorts sources: command execution failed
Please run `port -v selfupdate' for details.
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing
MacPorts sources: command execution failed
It is same for any software i am trying to download using macport. How to solve this issue?
Is it because my college firewall is blocking downloads using macport? Which port do macport use to download?
And also if they are blocking it how come linux users can download using yum, apt-get etc
You can run sudo port -d selfupdate to see why the update fails. I'm assuming it's because your local network blocks outbound access to port 873 (rsync), which MacPorts uses for updating. You should really ask your network administrator to allow outbound rsync – there's really no danger whatsoever associated with it.
To my knowledge, MacPorts is the only package manager, which uses the rsync protocol, so that explains why yum, apt-get and others work fine.
The synchronization failure also explains why the gnuplot port doesn't exist for you. MacPorts needs a file that tells it how to get and build gnuplot, which it downloads using rsync. If that never worked for you, you don't have the file and hence MacPorts assumes there is no gnuplot port.
If your network administrators refuse to open the rsync port (for whatever reason), there's an FAQ entry to work around that, as well: http://trac.macports.org/wiki/FAQ#selfupdatefails.
I need to monitor the performance of a raspberry PI (with raspbian), I tried to use new relic, but it doesn't support ARM architecture, so it's impossible to use.
I even tried graphdat but seems to have the same problem.
Any alternative to suggest me?
Linode Longview does support arm architecture:
https://www.linode.com/longview
The free tier have 12-hour retention but that may be enough for most cases.
I know this is old, but New Relic has ARM and ARM64 infrastructure agents now:
https://download.newrelic.com/infrastructure_agent/binaries/linux/arm/
I've tested this on a Raspberry Pi 4 (8GB) on Debian (32-bit) and it's been working fine so far.
In case anyone else tries, here's what I did:
Download the Infrastructure Agent:
sudo curl https://download.newrelic.com/infrastructure_agent/binaries/linux/arm/newrelic-infra_linux_1.20.5_arm.tar.gz --output newrelic-infra_linux_1.20.5_arm.tar.gz
Extract the files
sudo tar -xf newrelic-infra_linux_1.20.5_arm.tar.gz
Add license key to the config script:
echo "license_key=\"<YOUR_LICENSE_KEY>\"" | sudo tee -a ~/newrelic-infra/config_defaults.sh
Install the Infrastructure Agent
sudo ~/newrelic-infra/installer.sh
Check service status to make sure it's running:
sudo systemctl status newrelic-infra
By default, process information is not sent to New Relic, so I had to enable it manually:
echo "enable_process_metrics: true" | sudo tee -a /etc/newrelic-infra.yml
Finally, restart the service:
sudo systemctl restart newrelic-infra
ginnyweasley:~ s66$ sudo port selfupdate
Password:
---> Updating MacPorts base sources using rsync
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing MacPorts sources: command execution failed
I have tried to redownload macports and it still does not seem to work. I have also tried it without sudo and it still does not work. Does anyone have a solution to this problem? thanks.
I had that problem too. Even, like you, I re-downloaded the distribution and reinstalled.
That is until I read the manpage and tried the '-d' flag so
sudo port -d selfupdate
I tried it and surprisingly didn't find a command failing but successful completion. I didn't see any ports updated, but perhaps the error we saw were occurred after the ports tree was updated.
If it doesn't work, try it anyway, it'll at least point you in the right direction.
I had the same problem after upgrading to Yosemite, but since I found this post, I did not reinstall macports - I ran "sudo port -d selfupdate", had errors with c compiler failing, so I updated Xcode, ran "sudo port clean expat" after restarting, then ran "sudo port -d selfupdate" and all was well - thx you!
I'm programming application using libpcap. when I debug the application in normal mode, pcap cannot get the network device. it seems that I have to debug the application in root.
How can I debug the application in root? I have the root password.
I think eclipse has such an option that can add root for the debugging application,but I don't know how to do it.
please help.
Enable your user to run gdb as root without being asked for any
password:
sudo visudo
Add the following line after all other rules:
<youruser> ALL=(root) NOPASSWD:/usr/bin/gdb
Create or modify a debug configuration in eclipse to run gdb as root
e.g. in Run > Debug Configurations > C/C++ Application > YourProject Debug:
change Debugger > Main > GDB debugger from gdb to sudo -u <youruser> gdb
Update (and warning!):
In his comment nategoose pointed out that this answer should come with a warning:
Enabling a user to use sudo for gdb like suggested in my answer in fact gives admin privileges to him/her which in many cases might be an undesired side effect. I therefore consider the answer appropriate in an environment where it's not assumed that the user would try to harm the system (e.g. it's your own personal computer or a virtual machine)
For a multi-(non-trusted)-user environment I think it might be a better idead to utilize unix' file capabilities to enable gdb to debug an application without the need of admin privileges
You can use gdbserver on localhost to attach a existing process, the following is the command line:
sudo gdbserver :<listening port> --attach <pid>
Or you can create a new process using gdbserver:
sudo gdbserver :<listening port> <process executable>
Then you can create a debugging configuration in Eclipse, in the debugger tab, the debugger item, select gdbserver, and input the listening port in the connection tab in the bellow.
Launch Eclipse with sudo (just for completeness: http://www.eclipse.org/forums/index.php?t=msg&goto=516838&)
Update: Follow xmoex solution. If you run Eclipse as root (ie. using sudo) your files will be root-owned... which you probably don't want.
Another solution is to grant you (or the gdb executable) the rights to make some pcap captures as mentioned here. With something like this :
setcap cap_net_raw,cap_net_admin=eip /usr/bin/gdb
you should be able to allow to capture packets to gdb without being root.
Here's how I did it:
Create a C/C++ Remote Application
On the target, make sure your sudo does not prompt for a PW
Look at Debug Configurations → Debugger → Port number
Edit Debug Configurations → Main → Commands to execute before application
Change to:
sudo gdbserver :<port number> <path to application>;exit #
This will basically run the gdbserver that would normally be executed by eclipse inside the sudo, the trailing '#' will keep the eclipse command from executing.
this question was asked a long time ago but if this will help to anybody I open a bug in bugzilla and this short thread solved the problem:
bugzilla bug
From the console in the directory with your executable:
sudo gdb ./my_program
If eclipse supports remote debugging then you could do that even though it is running locally.
From the console:
sudo gdbserver localhost:<port_number> ./my_program
And then tell Eclipse the address (localhost and the port number you chose).
Oh yeah, you said the reason you were doing this was because you were using libpcap, so you may not want to use remote debugging over TCP because you may end up capturing your debugging connection packets in addition to your other network traffic.
In that case you do your remote (but really local) debugging over a serial port. I have never done this on a local machine, but you could use two actual serial ports (attaching them though a null modem) or try using a psudoterminal:
sudo gdbserver /dev/ptmx ./my_program
This will create the psudo-terminal under /dev/pts/ but you'll have to figure out the name of it, and it might also create it with restrictive permissions. You can get around those. Unless you are running lots of terminal windows as root, it is not likely that you have many entries under /dev/pts that belong to root, so take note of the one that does after running the above command and then sudo chmod or sudo chown it to make it usable for your normal user and then tell your debugger to use that as your serial connection to your remote debugging target.
easiest way, try sudo ./eclipse, then debug as usual