I was trying to display the time to see if I had the timezone correct... instead of the command 'clock'(which I know is not right now) I used 'vlock'. This locked my terminal while I was setting up archlinux. Now I am stuck on a screen that says
"The tty1 is now locked by root. Use Alt-function keys to switch to other virtual consoles.
Password:"
And I do not remember setting up a password so I do not know how I could guess correctly. Is there a way to undo the vlock? or should I just start a new archlinux VM?
Related
I have installed CouchDB on my Windows machine but while starting the CouchDB service, I am getting a message like:
Windows could not start the Apache CouchDB service on Local Computer. The service did not return an error. This could be an internal Windows error or an internal service error. If the problem persists, please contact your system administrator.
As the service is not running, I am unable to access Fauxton too.
I am using Windows 7. CouchDB is 2.0.0. Port 5984 is not in use.
I don't think your question is a duplicate of https://stackoverflow.com/a/44107335/219187 because you are on Windows 7, and the problem described there is for Windows 10 with the creators update.
But maybe the solution fixes your problem as well? Here is the procedure:
Download the prelease build 2.2.4-101 from https://nssm.cc/download
Stop the CouchDB service through the Windows Services dialog (paused is not enough)
Overwrite nssm.exe in <CouchDbInstallDir>\bin with the one from the downloaded ZIP file (make sure you pick the right version 32 bit / 64 bit)
Start the CouchDB service
Issue it's happening since the last updates released by Microsoft. I'm not completely aware of what's causing it, but I think it's something related to CouchDB service not been able to start using Local Administrator rights.
However I've managed to start the service manually, by doing so:
Open Command Prompt - in the Search from the Start Menu or Task Bar type "cmd"
Run it as an Administrator - right click on the Command Prompt application and choose "Run as administrator" option /this is really IMPORTANT as it will allow the service to have administrator access/
Navigate to the folder where CouchDB is install - default path is "D:/CouchDB", but could be anywhere else; you have to find it
Go to the "bin" folder in there
Type "couchdb" as a command to start the service
You will see a message showing after this - "kernel-poll not supported; "K" parameter ignored"
If it adds some error messages after it or closes the whole terminal, you're making some things bad from this guide, so follow it strictly.
You can now open up the Fauxton application in the browser like normal from here - http://localhost:5984/_utils/
Keep in mind that you have to leave the cmd opened in order the service to be working as expected. As far as I saw no information was lost, so it's all good.
This is a temporary solution though, as we are waiting a relase from either Microsoft or Apache to solve the issue, or at least give us more explanation about it.
i just met the same problem.
the cause is space, you have to install CouchDB in a path without any space, even Program Files folder, because there is a space between Program and Files...
I currently am using Cmder (which is effectively conemu) to SSH into a university cluster from my Windows machine. I want to enable x-forwarding, and I have Xming installed. I followed the instructions here, which I swear I've used before but doesn't seem to work right now. Specifically, I type
DISPLAY=localhost:0.0;export DISPLAY;
once I open up a Cmder terminal (with Xming already loaded), but the error I get back is
Error: cannot open display: localhost:0.0
despite Xming saying it is Xming server:0.0. Any suggestions? I should add that the x-forwarding works perfectly fine with MobaXterm, but I'd prefer to stick with Cmder.
The issue was that I was setting the display variable on the client server, not the host computer. On my Windows machine, I opened Xming and then did
set DISPLAY=127.0.0.1:0.
Afterwards, I SSH'd into the client server via
ssh -X myname#address.
Now everything works as intended.
I have exactly the same problem. However, I have observed that if I open up a Putty session with x11 forwarding set, then add the display number to my ConEmu session that is ssh'd into the Linux box, then x11 works from ConEmu. Weird.
It is an inconvenient workaround at best.
I made it work for me.
Even so Xming was telling me "localhost:0.0", after connecting to the my server (using the "-x" ssh's option) I rather did :
DISPLAY=:10.0;export DISPLAY;
The following worked for me:
export DISPLAY=127.0.0.1:0
ssh -XC <hostname>
I am launching a launchAgent from a post install script using the following command:
su -l $LOGGED_IN_USER -c "/bin/launchctl load /Library/LaunchAgents/com.myApp.mac.agent.plist"
The agent displays a status item (NSStatusItem) with a couple of menu options. One of them has a settings option. Clicking this will open an NSWindow, with few NSTextFields. At times, though this window is the top most, whatever I type goes to the underlying app. I am unable to type anything into the text field. Whenever this happens, I notice the following log in the console:
WindowServer[97]: [cps/setfront] Failed setting the front application to MyApp, psn 0x0-0xb20b2, securitySessionID=0x186c5, err=-600
This is not a consistent behaviour. Any idea why this log comes? And is there any work around for this? Is it ok to launch the agent using su -l?
I don't know exactly why you're getting that error and behavior. I recommend reading Technical Note TN2083: Daemons and Agents. It explains in detail the various facets of the execution context of a process and how that affects what a process can do. That includes whether or not a process can connect to the Window Server.
For what it's worth, error -600 is procNotFound, whose description is "no eligible process with specified descriptor". It seems that the Window Server is not able to find a process with the given process serial number (PSN) in the given security session.
I would not use -l in your sudo command. A user's login scripts can do all sorts of crazy things and you don't those done by your installer. However, I don't believe that's related to the main problem.
I've got a Windows 7 machine setup with vagrant/virtualBox - each morning when I try to access my development site it always a 'Unable to connect' error message in my Firefox browser.
Even though I have booted the machine using the 'vagrant up' command for some reason it only seems to be accessible via the browser once I have done the 'vagrant provision' command. This is obviously annoying as it starts doing stuff from scratch.. eg installing my mysql database again.
Can anyone provide any light into this, and why it seems to fail to connect all the time - as this provision command is only a temporary fix as i'll need to amend the DB everytime which is only feasible in the short term.
Might just be my own setup - but I noticed nginx was restarting so have to restart this each time
I use PuTTY sessions to talk to an embedded device running QNX 6.4.1 using SSH over TCP/IP.
Today, one of my systems mysteriously won't allow me to have more than one PuTTY session open at a time. If I try to start a second session, I can authenticate with user name and password, but the sign on banner prints out with an extra blank line between each line and messes with my ability to hit enter. I can do nothing that looks remotely valid except Control-C or close the PuTTY window.
I suspected the text file that contains the banner had bad line
endings, but it does not.
I suspected terminal setting issues, but if I have one session open it
works. With no changes to settings, just trying to open a second session it
does not.
I wondered if the .profile was getting mangled, but that doesn't
seem to be the case either.
Now I'm down to "perhaps ssh is messed up and rebooting would fix
it?" But I am hesitant to reboot it because if we lose TCP/IP
connection to it, it's several hours worth of work (physical labor)
to restore.
Any thoughts about what is going wrong and how I can fix it?
I'm connecting using PuTTY 0.62 from 64-bit Windows 7 to QNX 6.4.1. The openssh/openssl version is modern.
UPDATE
The issue came back a few days later. Using Guntram Blohm's suggestion below, I was able to at least get past the "Press enter once you've read the banner" screen. I then ran stty sane ctrl-j as he recommended. Here is the output of stty:
Bad after I had run stty sane ctrl-j (And hand reformatted it to be readable)
Name: /dev/ttyp1
Type: pseudo
Opens: 3
+raw +echo
+osflow
intr=^C quit=^\ erase=^? kill=^U eof=^D start=^Q stop=^S susp=^Z
lnext=^V min=01 time=00 pr1=^[ pr2=5B left=44 right=43 up=41
down=42 ins=40 del=50 home=48 end=59
I then opened another PuTTY session immediately after this and it worked properly. This is confusing me how it works sometimes and doesn't work others. How can that happen? What is different?
Good
Name: /dev/ttyp2
Type: pseudo
Opens: 2
+edit
+osflow
intr=^C quit=^\ erase=^? kill=^U eof=^D start=^Q stop=^S susp=^Z
lnext=^V min=01 time=00 pr1=^[ pr2=5B left=44 right=43 up=41
down=42 ins=40 del=50 home=48 end=59
So right now I have a good PuTTY terminal open, and a bad one. What else can I do to isolate this issue?
It's probably another process that uses the pseudo-terminal, puts it in a special state, then crashes without restoring the state. vi comes to mind, or maybe a file upload/download program. These programs change the terminal mode to read each character indicidually, instead of line by line, and tweak a few other things as well. Normally, logging out/back in SHOULD fix that, but i'm not sure QNX handles it correctly.
One thing you could do to copy the parameters of a working terminal to the messed up one is stty -g on the good one, then paste that output to the command line of the bad one. Like this (on Linux, i don't have a QNX at the moment):
(on the good terminal)
gbl#bermuda$ stty -g
500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
(on the bad one)
gbl#bermuda$ stty 500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
These terminal modes are kept per pseudo tty device, that's why your /dev/ttyp1 can be messed up, while the /dev/ttyp2 that's allocated for the next ssh connection is ok.