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
adb server version (39) doesn't match this client (40); killing...
could not read ok from ADB Server
* failed to start daemon
error: cannot connect to daemon
adb: error: failed to get feature set: protocol fault (couldn't read status): Connection reset by peer
* daemon not running; starting now at tcp:5037
* daemon started successfully
- waiting for device -
error: protocol fault (couldn't read status): Connection reset by peer
I have the same issue when running adb devices command.
adb devices
List of devices attached
adb server version (36) doesn't match this client (40); killing...
* daemon started successfully
2322dc3d device
I ran command which adbwhich gave me the location of the adb that the previous command was using, in my case output was:
which adb
/usr/bin/adb
Then i ran whereis adb command which gave me the location of adb's:
whereis adb
adb: /usr/bin/adb /home/arefin/Android/Sdk/platform-tools/adb
/usr/share/man/man1/adb.1.gz
I get rid of this problem by moving the adb from /usr/bin directory with mv command: (meaning this is of no use thus instead of deleting just put in desktop),
/usr/bin$ `sudo mv adb /home/arefin/Desktop/`
After this i executed this command adb kill-server then ran adb devices. I found everything is fine this time.
My Android development related path in in $HOME/.profile file is, as below:
export ANDROID_HOME=/home/arefin/Android/Sdk
export PATH=$PATH:$ANDROID_HOME/platform-tools
export PATH=$PATH:$ANDROID_HOME/tools
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$JAVA_HOME/bin
When encountered this error in Linux,I deleted the adb file in my
/usr/bin/
and replaced with one which located in path (usually in home path)
~/Android/Sdk/platform-tools/
and it worked.
As pointed out in previous answers, this is due to having multiple adb versions installed in your system. Probably one from the android-sdk-platform-tools installed via apt and other from Android Sdk itself (which is usually newer version).
The simplest way to solve this in Ubuntu (or Ubuntu-based OS's) is to add this line at the end of ~/.bashrc file:
alias adb='~/Android/Sdk/platform-tools/adb'
#Change path according to your Android Sdk installation directory
And then reopen terminal for changes to reflect.
This avoids the need to mess with system files as well.
Probably you have two versions of adb in two different locations in your system. The running server version is 39 and the adb client version is 40. You can resolve this by keeping only one adb in your PC.
You can figure it out as shown below-
In Linux below command gives you adb location if adb binary is added to path.
which adb
if adb is not added to path and still you are getting this error then search for adb using below command.
locate adb
if your adb client is other than above location, you may add newest version to above path and delete the old adb version.
If you are using windows, you figure it out the two adb locations and keep only at single place.
I know this is a little old, but if you have this problem and you have Vysor installed, then you can resolve it by looking in the Vysor application folder for the adb.exe (and Adb*.dll files) and replacing them from your Android SDK folder. I'm on a Windows machine and the relevant paths for me were:
Vysor
C:\Users\\AppData\Roaming\Vysor\crx\gidgenkbbabolejbgbpnhbimgjbffefm\app-2.1.7.crx-unpacked\native\win32*
(I'm guessing the path will vary according to the version, etc, but this will hopefully help figure it out.)
APK
C:\Users\\AppData\Local\Android\Sdk\platform-tools
On my machine, the relevant files were:
adb.exe,
AdbWinApi.dll,
AdbWinUsbApi.dll
After this, you will need to kill the existing ADB task as described in the other answers to this post.
Solved by
Open terminal in Android studio
adb kill-server
sudo cp ~/Android/Sdk/platform-tools/adb /usr/bin/adb
sudo chmod +x /usr/bin/adb
adb start-server
Run
tasklist | findstr adb
then kill the duplicate process
TASKKILL /PID "PID_NUMBER" /f
Encountered this problem myself, none of the solutions online worked for me.
did this by chance and it solved my problem!
I'm using Android Studio on a Macbook Pro.
first I tried to install adb from brew:
brew cask install android-platform-tools
then I uninstalled it:
brew cask uninstall android-platform-tools
After the last line adb didn't work in terminal but did work in Android Studio immediately! =D
posted so it may help someone else - good luck!
For ubuntu (more precise - kubuntu) i had the similar problem.
The problem was in android-studio, to fix it you need to do these steps:
Go to SDK-Manager
In SDK-Manager click the SDK Tools menu.
Uncheck "Android SDK Command-line Tools (latest)"
I had the same issue connecting to my SFTP Server app and could solve it as follows:
The error was caused (in my case, Ubuntu 18.04.5 LTS) by conflicting adb installations. One Installation coming with AndroidStudio (IntelliJ) located in .../Sdk/platform-tools and one coming with the package manager installation apt install located in the standard directory for executables /usr/bin. The installation location for AndroidStudio (IntelliJ) can be found in the AndroidStudio (IntelliJ) Menu: Tools → Android → SDK Manager: Android SDK Location. And the installation location related to the package manager can be found invoking the command which adb.
And the solution to this problem is to uninstall one of them.
Depending on your use case, if you’re most of the time working with AndroidStudio (IntelliJ) (and this version is up to date), then remove the (outdated) version installed with the package manager as follows.
To uninstall first find out which packages relates to /usr/bin/adb with the following command: dpkg -S /usr/bin/adb.
And then call apt autoremove adb to uninstall the adb package and all its dependencies.
And last but not least in order to still being able to call adb from the command line update the PATH variable in “/etc/profile”, if it should be accessible for all users, or ~/.bash_profile or ~/.profile (whichever exists) if it should only be accessible for the current user and append the path “.../Sdk/platform-tools” (that you looked up above) at the end. And then reboot or log-out & log-in for the new path to get applied.
In ubuntu
delete the adb
-> usr/bin
-> (delete command) sudo rm -rf /usr/bin/adb
Android/Sdk/platform-tools/adb
-> copy this folderpath.
paste into
->usr/bin
->(paste command) sudo ln -s /home/yourfile/Android/Sdk/platform-tools/adb /usr/bin
restarting your system, would also work for you.
I have faced the following error and what worked in my case was just to restart the system.
could not read ok from ADB Server
* failed to start daemon
error: cannot connect to daemon code here
adb.exe: failed to check server version: cannot connect to daemon
I had a similar error. Two different adb versions were conflicting with each other which caused it to keep restarting.
Run this command in terminal => where adb.exe
This will show you where the different adb files are. You can look at the file property date to see which is the latest one. Then copy the latest one and use it to overwrite/replace the older one(s). This will make both adb versions be the same and prevent a conflict.
This generally happens when there are two adb paths are available. Uninstall one will help
--> npm uninstall adb
This worked in my case.
None of the other solutions worked for me - Windows/WSL2-Ubuntu
The error is misleading but for me it was cos the adb port 5037 was in use.
Solution: find and kill the process using port 5037
Windows: netstat -aon | findstr 5037 and Stop-Process -Id <id-from-netstat>
WSL will attempt to connect to Windows port 5037
In my case wsl Ubuntu has different adb --version than Windows, I don't have to keep my Android Studio latest(since this might not your choice and do not guarantee same version as apt) or try with $PATH(wsl run Windows exe is not make sense).
The solution is simple, I download both Linux and Windows SDK Platform-Tools from official site which guarantee same version, then invoke relevant adb on each platform.
In my case I'd installed "AirDroid" on my windows machine and it runs "AirDroid_adb.exe", I had to kill that to get things to work. I have reported that they are using an old version of adb and they will hopefully fix it.
A Working Simple Answer for Windows:
make sure you have the sideload file (whatever.bin) in a sub directory of your adb executable.
make sure your adb executable folder, and sub directories are in PATH (look up DOS commands for PATH in Windows)
open a command prompt in the same directory as the sideload file
enter your command for example:
adb sideload mynewrom-5.4.3.2.1.bin
(Your device needs to be in recovery - sideload state before you send)
I have an issue to install MSSQL on my Linux(Ubuntu 16.04) Server.
I have used the manual from Microsoft but I always fail on the same stage.
Actually, Docker is not an alternative due to Kernal issues.
After:
sudo apt-get install -y mssql-server
I'm supposed to do
sudo /opt/mssql/bin/mssql-conf setup.
This returns after answering all questions:
sqlservr[8383]: sqlservr: The configuration file '/var/opt/mssql/mssql.conf' failed to load (error: The INI file could not be opened. Errno [2] Filename [mssql.conf]).
I can access the config file and it seems to be usable by the script as well.
My Linux skills are not good enough to resolve this issue.
To answer some questions that were raised:
I tried sudo
cat the file returns the content as expected
Try running mssql server as root first (stop the service, run it as root, with /opt/mssql/bin/sqlservr) and see if it works that way. If it does, stop the mssql server and fix the ownership of the mssql dir with sudo chown -R mssql:mssql /var/opt/mssql). More info on this answer.
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