I'm having some problems getting the XFCE Power Manager to lock using physlock. When I set the Lock Screen on Lid Close action, upon opening my laptop lid I'm presented with an alternate lock screen, and after entering my password I get the error None of the screen lock tools ran successfully, the screen will not be locked.
However when I manually run xflock4 from a terminal emulator, physlock is correctly used.
The relevant xfconf LockCommand setting is thus:
➜ ~ xfconf-query -c xfce4-session -p /general/LockCommand -v
physlock
And my power manager settings are this:
physlock was correctly working in the past using these settings, but as this stopped working some months ago, I'm afraid I won't be much help in narrowing down what triggered the initial change.
Related
When I use screen, it works fine except up to the point where I need to re-attach. My suspicion is that the sort of "shelled" environment I am using is not letting screen fully detach although I am unsure of whether that is the case.
My current environment is this: ssh -> cygwin bash shell -> screen
Everything works fine but when I try to attach with screen -r (id), the command doesn't do anything, I don't get any output and when checking with screen -ls the screen session is still listed as detached. I researched this but can only come up with other people who either get a dead screen session or some error. I don't get either, the command runs and gives no output leaving the screen detached. I have a feeling this is something to do with screen not detaching fully because of the layered shells but have no idea how to fix it.
Any suggestions?
When I restart or shut down and start my computer, I have the following. After sleep mode it doesn't show the question marks when signing into my account. Tried the advice below but it doesn't work:
Fix Font Corruption
Open Terminal in your Utilities' folder and paste the following after the prompt:
fontrestore default
Press RETURN.
If this doesn’t fix the problem then paste the following after the prompt:
sudo atsutil databases -remove
Press RETURN.
You may need to restart the computer for anything to take effect.
Using Macbook Air with Mojave.
I have designed a GUI that I want to run as soon as I turn on my Raspberry Pi. It is currently set up to automatically log in as user on startup, but if that makes the process more difficult I can change that. My Raspi runs on Raspbian 10 (buster), which has made things difficult since I can only find tutorials for Raspbian 8 or so.
I have tried modifying autostart folder, but it is not in the same location as it was in previous Raspbian versions and doesn't seem to be working the way it used to. Tutorials have said to create a .desktop file in /home/pi/.config/autostart but I don't have a .config folder, or at least it's hidden. For me, autostart is in /etc/xdg/autostart and when I try to create a new file here using nano in the terminal, I get the message [Directory '/etc/xdg/autostart' is not writable] and it doesn't save my file.
I have also tried calling my script in /etc/rc.local but it did nothing. Some have said it doesn't work for GUIs.
Here's what I type into terminal:
$ nano /etc/xdg/autostart/gui.desktop
and a new file pops up, but at the bottom I get the warning [Directory '/etc/xdg/autostart' is not writable]
How can I get my GUI script to run on startup with Raspbian 10 (buster)?
There are a number of issues here, first when you are looking at tutorials recognize that Linux distros are built in layers, for simplicity let's say your "layer stack" looks like this: kernel, systemd, x11, xdg, lxde. The kernel boots, then starts systemd, which then starts x11 (and a lot of other stuff), x11 starts xdg (and some other stuff, I think), lxde is started by either x11 or xdg I'm not sure which.
You want to add something to this process, you can do it at the kernel level (bad idea), at they systemd level (probably not right unless its a daemon), at the x11 level (still probably bad as you still don't have a user session yet), or at the xdg or lxde level.
xdg is probably the right place as it has all you need ( a gui, a user session) while being common (xdg will still work if you switch window managers, probably)
With that out of the way, why isn't your solution of modifying xdg working? It's because '/etc/xdg/autostart' is a system configuration directory. Any changes made to it will apply to all users. You may want this, but the system is trying to protect other users on your system and only allows root to make changes to everyone. If you want to do that use "sudo" (documented elsewhere on stack exchange and the internet). If you want to do it just for you use ~/.config/autostart, (https://wiki.archlinux.org/index.php/XDG_Autostart) you might need to create that directory with "mkdir ~/.config/" and then "emacs ~/.config/autostart"
Would it be better to have the python program run in a terminal window from startup? That way you would see what it is doing in case of errors.
If so, perhaps check this out https://stackoverflow.com/a/61730679/7575617
By the way, in the file manager, hit CTRL+H to toggle viewing hidden files and folders.
I have been using ConEmu for some time to run 'bash for windows', but all of the sudden it stopped working. When I launch a bash tab it now says:
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
I think this means that it launched something, but the shell closed quickly. I haven't changed anything that I can recall with the system, it just started doing that.
Windows version: 10 (build 15063)
ConEmu version: 180626 preview
No windows updates were done recently.
If I launch 'Bash on Ubuntu on Windows' from the start bar, it works fine (but I prefer using conemu as a terminal). Also, I can launch a cmd tab in conemu, then type bash and the bash shell will start. Unfortunately, launching bash in this way results in a lack of mouse support, and strange arrow key behavior.
I am at a bit of a loss. It worked perfectly previously... then it just stopped. Any help on how to debug or fix this would be appreciated.
If anybody finds this with a similar problem, my solution was to make a new task in ConEmu, with the command:
%windir%\system32\bash -l -i -cur_console:p5
The key is the -cur_console:p5, which sets the pty type as:
p[N] - pty modes, N - bitmask: 1 - XTermKeys, 2 - BrPaste, 4 - AppCursorKeys; default is 5 (1+4)
For some reason, setting p5 is necessary for me, despite it being listed as the default. Still not sure what changed, but at least it is working now.
I have the same problem but (for what it's worth) found that when it happens (varying between intermittent and incessant) restarting my machine fixes the issue every time.
I use tmux 1.6-2 on a Debian 7.6 (wheezy).
I open a new session and start a long running script that gives updates in form of a progress bar and an activity indicator (spinning bar: /-\|/ ).
When I detach and reattach everything is still fine. But after some random time when I reattach the screen content is stuck. No spinning bar, no progress. I looked into the following:
I can see in top that the process is still running
I can successfully enter tmux commands (like new window, detach, etc.)
I can kill the script with Ctrl-C, but the tmux screen doesn't change
Ctrl-S and Ctrl-Q (like suggested in other threads) doesn't help
Any help is very much appreciated.
I managed to unfreeze my tmux session by running choose-client command from tmux's command line <prefix> :
where prefix is C-b by default
I found the solution in the bug report (by Taisuke Yamada).