I was having some issues with switching my audio output (ie I plug in HDMI, if an application is currently running its audio through the computer's speakers, the audio does not move to the HDMI unless I kill the pulseaudio session and restart the program) and tried adding some scripts that run at login but can't remember what they are (not smart). I know I put, for example, pulseaudio -k somewhere.
Anyway, I get to a login screen as usual but after I enter my credentials it flashes the dell screen then goes right back to login. I can login using the terminal. I am certain that I broke my system when adding these custom scripts as something related to them comes up after I login using the terminal.
I just want to basically reset my desktop without losing my files, and perhaps internet bookmarks, as I have given up on trying to see where the offending code is, but if there is an easy way to find this then I'm all ears. Maybe there is a way, for example, to restore my desktop to its factory settings from the terminal without touching my documents?
Ubuntu 19.10 PHILLIP-Precision-5520 tty
PHILLIP-Precision-5520 login: PHILLIP Password:
Last login: Sun Apr 19 13:46:31 EDT 2020 on tty4 Welcome to Ubuntu 19.10 (GNU/Linux 5.3.0-46-generic x86_64)
* Management:
* Support:
* Documentation: https://help.ubuntu.com https://landscape.canonical.com https://ubuntu.com/advantage
0 updates can be installed immediately.
0 of these updates are security updates.
Failed to connect to https://changelogs.ubuntu.com/meta-release. Check your Internet connection or proxy settings
Failed to kill PulseAudio daemon.
Toggling output devices (Speakers/Headset) No PulseAudio daemon running, or not running as session daemon.
No PulseAudio daemon running, or not running as session daemon.
No PulseAudio daemon running, or not running as session daemon.
No PulseAudio daemon running, or not running as session daemon.
Moving input: to sink:
Setting default sink to:
Can't open display E: (pulseaudio) main.c: Failed to kill daemon: No such process PHILLIP (master #) $ ==
Related
Setup:
Embedded target device: Rock5B (ARM64)
Linux: Debian 11
Bluetooth stack: Bluez
Audio: Pulseaudio
Window environment: Xfce
I'm writing a Bluetooth application which connects to a headset.
If I manually log into window environment with user credentials and do manual Bluetooth pairing and select manually the output sink it does work as expected.
The same happens if I log into window environment and I run my application remotely using SSH which connects to Bluetooth headset and run the script remotely using SSH and selecting the output sink number 3 (which in that case is Bluetooth headset):
pacmd set-default-sink 3.
On the other hand if the device get started but I do not log into window environment but instead just run same steps remotly using SSH then Blutooth pairing is completed but the Pulseaudio sink number 3 is not present.
I have tried after restart to first run the Pulseaudio manually:
pulseaudio -k
pulseaudio -D
and after that I have run remotely using SSH my app and then select the sink with pacmd. Now pacmd found and selected the sink but when I tried to run the audio file remotely there was no audio output:
PULSE_SERVER=127.0.0.1 cvlc audo.wav
Again if I log into the window environment run everything remotely and run above cvlc the audio is working fine.
Something needs to be setup more than that when windows environment is starting but I can not figure what.
I have a PC that transmits log data over a TCP/IP socket to a Raspberry Pi. I have written a python server program that runs on the Pi, so that when certain keywords are encountered, it has to play the corresponding audio track - this is a gist of the problem I'm currently working on.
Now, I want this server program to run as soon as the Raspberry Pi boots up, and so I wrote a systemd service to enable that. Assuming my server code is named as server.py, my service file looks as follows:
[Unit]
Description=Python Server
[Service]
# Command to execute when the service is started
ExecStart=/usr/bin/python3 -u /usr/bin/server.py
[Install]
WantedBy=multi-user.target
I make this server program executable, and I don't face any issues to start and enable the service (verified by rebooting the Pi as well). Now, taking a step back, I play the audio track on the python server program using the following lines (a little snippet):
import subprocess
subprocess.run(["cvlc", "~/Downloads/doors.wav"])
No errors here, all good. But when the service that runs the server program is started, when the specific keyword is encountered, the audio track does not play - it shows an error:
: [00005565470df480] vlcpulse audio output error: PulseAudio server connection failure: Connection refused
: [0000556547157310] dbus interface error: Failed to connect to the D-Bus session daemon: Unable to autolaunch a dbus-daemon without a $D
: [0000556547157310] main interface error: no suitable interface module
: [000055654700c570] main libvlc error: interface "dbus,none" initialization failed
: [0000556547101460] main interface error: no suitable interface module
: [000055654700c570] main libvlc error: interface "globalhotkeys,none" initialization failed
: [0000556547101460] dummy interface: using the dummy interface module...
: [00007f5f98c0b610] idummy demux: command `quit'
This same error shown above occurs when I try to play the audio from the command line with sudo, that is:
cvlc ~/Downloads/doors.wav
which led me to believe that if the service is enabled, then the whole python program corresponding to the service is run with sudo privileges automatically, even if I don't intend that to happen. I did a little bit of digging, but based on what I understand, to run the service, sudo privilege is necessary. I was not able to find a solution to run vlc with sudo, although I understand that ideally sudo privileges should not be given to something such as vlc. Is there a way around this?
This is happening because the PulseAudio server runs under your user, not as root. The service you are starting runs as root and tries to connect to root's PulseAudio server.
You can run specify which user/group to run the service as under the [Service] section with the User and Group directives.
You can also run the service as your user like this:
$ systemctl start --user <service>.service
I'm trying to automatically call a program at boot that uses Bluetooth. However, the program is being called before Bluetooth is configured and running.
I've tried calling the program in two ways:
Using a script in init.d and registered with update-rc.d with this line in the init: # Required-Start: $all
Calling it from /etc/rc.local
Neither of these work as desired. They both start the program, but before Bluetooth is configured and running.
What is the best way to force a script or program to run after Bluetooth?
Below are some select lines from the boot sequence so you can see the issue I'm having:
[ OK ] Started Login Service.
[ OK ] Started Getty on tty1.
**Where my program is currently executing**
[ OK ] Started Configure Bluetooth Modems connected by UART.
[ OK ] Reached Target Bluetooth
**Where I want my program to be executing**
Raspbian GNU/Linux 8 tty1
login:
The new init system for Debian 8 "Jessie" is systemd. The old way in Debian 7 "Wheezy" was Sysv with runlevels and /etc/inittab. A drawback of using crontab to run your program will be, if the script execution crashes, it dies forever. Restarting a script automatically if its ends is called "respawn".
As you can see, the Bluetooth Service is running and prints that a "Target" is reached. To create your own service, which runs after bluetooth startup, and respawns with systemd just create a file in /etc/systemd/system/ i.e. my_program.service
[Unit]
Desription=my_program with systemd, respawn, after bluetooth
After=bluetooth.target
[Service]
ExecStart=node /home/pi/workspace/my_program
Restart=always
[Install]
WantedBy=multi-user.target
and activate it
systemctl enable my_program.service
reboot or start it manually
systemctl daemon-reload
systemctl start my_program.service
If one kills the process or reboots, my_program will be restarted automatically some seconds later.
For anyone running Raspbian 9 (stretch)
I tried out #andpei's answer and my application still wasn't waiting for bluetooth to start up. I was able to solve this by adding "Requires".
[Unit]
Desription=my_program with systemd, respawn, after bluetooth
After=bluetooth.target
Requires=bluetooth.target
Using crontab, I was able to make it work with the following line:
#reboot sleep 5 && node /home/pi/workspace/my_program
Not ideal but it works for now. I'm open to any better answers.
I'm using this docker imagine from the docker repo: traxtopel/docker-centos-gnome-desktop
https://index.docker.io/u/traxtopel/docker-centos-gnome-desktop/
I have a Linux Mint system with Docker 0.9.0 installed that can run the image and launch vncserver with a gnome-session without any problems.
However, when I run the same image on my CentOS6 system (also docker version 0.9.0) and attempt to launch a gnome-session I get the following:
Failed to start message bus: Failed to open "/etc/selinux/targeted/contexts/dbus_contexts": No such file or directory
EOF in dbus-launch reading address from bus daemon
I also tried to launch a gnome-terminal which works in the Linux Mint host but produces the following on my CentOS6 host.
Failed to get the session bus: /bin/dbus-launch terminated abnormally with the following error: EOF in dbus-launch reading address from bus daemon
Falling back to non-factory mode.
Failed to summon the GConf demon; exiting. Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: /bin/dbus-launch terminated abnormally with the following error: EOF in dbus-launch reading address from bus daemon
)
Since both docker versions are the same, and they are using the same docker image, my only guess is it has to do with the hosts kernel version or possibly the hosts selinux configuration.
Linux Mint Kernel: 3.8.0-19-generic
CentOS6 Kernel: 2.6.32-431.5.1
Any ideas what is causing this behavior?
Looks like the issue has something to do with selinux. I don't have all the details or a "proper" fix but the Linux Mint system was not running selinux while the CentOS6 system was.
I had initially ruled this out since when selinux is put into permissive mode the same behavior occurs. Disabling selinux entirely and rebooting the host system fixes the issue though.
Trying to determine the root cause, I ran selinux in permissive mode and tailed the /var/log/audit/audit.log file however nothing is written out to the log concerning this issue when gnome-terminal or gnome-session is run from the docker image.
If anyone has any better solutions please post however it seems a solution is to disable selinux on the host system.
Since I install pending updates for my Ubuntu server as soon as possible, I have to restart my linux server quite often. I'm running an webapp on that server and would like to warn my users about the pending restart. Right now, I do this manually, adding an announcement before the restart, give them some time to finish their work, restart and remove the announcement.
I hope, shutdown -r +60 writes an file with all the information about the restart, which I can check on every access. Is there such a file? Would prefer a file in a virtual file system like /proc for performance reasons...
I'm running Ubuntu 10.04.2 LTS
If you are using systemd, the following command shows the scheduled shutdown info.
cat /run/systemd/shutdown/scheduled
Example of output:
USEC=1636410600000000
WARN_WALL=1
MODE=reboot
As remarked in a comment by #Björn, USEC is the timestamp in micro seconds.
You can convert it to a human friendly format dropping the last 6 figures and using date like this:
$ date -d #1636410600
Mon Nov 8 23:30:00 CET 2021
The easiest solution I can envisage means writing a script to wrap the shutdown command, and in that script create a file that your web application can check for.
As far as I know, shutdown doesn't write a file to the underlying files system, although it does trigger broadcast messages warning of the shutdown, which I suppose you could write a program to intercept .. but the above solution seems the easiest.
Script example:
shutdown.bsh
touch /somefolder/somefile
shutdown -r $1
then check for 'somefile' in your web app.
You'd need to add a startup link that erased the 'somefile' otherwise it would still be there when the system comes up and the web app would always be telling your users it was about to shut down.
You can simply check for running shutdown process:
if ps -C shutdown > /dev/null; then
echo "Shutdown is pending"
else
echo "Shutdown is not scheduled"
fi
For newer linux distributions versions you might need to do:
busctl get-property org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager ScheduledShutdown
The method of how shutdown works has changed
Tried on:
- Debian Stretch 9.6
- Ubuntu 18.04.1 LTS
References
Check if shutdown schedule is active and when it is
The shutdown program on a modern systemd-based Linux system
You could write a daemon that does the announcement when it catches the SIGINT / SIGQUIT signal.