I am using Manjaro Linux and a while ago pulseaudio has stopped working (after an update, I assume, I did not change any configuration manually).
The symptoms:
In KDE, no sound device is found
Pulseaudio volume control cannot connect to Pulseaudio
ps x | grep pulse returns no running processes.
pulseaudio -k says no pulseaudio process is running.
However, Applications still play music using the speakers. I just cannot adjust the volume.
When running "pulseaudio" I get the following output
W: [pulseaudio] pid.c: Stale PID file, overwriting.
N: [pulseaudio] alsa-util.c: Disabling timer-based scheduling because running inside a VM.
N: [pulseaudio] alsa-util.c: Disabling timer-based scheduling because running inside a VM.
N: [pulseaudio] alsa-util.c: Disabling timer-based scheduling because running inside a VM.
zsh: killed pulseaudio
When I run "pulseaudio -D -v" I get the following output:
[pulseaudio] main.c: Daemon startup successful.
When I run "pulseaudio -k" afterwards it says it cannot abort the process because it could not been found. Also, "ps x | grep pulse" does not list any running process.
Any hints how to fix this?
Related
I am currently working on the ARM Cortex-M4 inside the NXP i.MX8M Mini.
I am able to compile a project for M4 on Eclipse IDE on an Ubuntu VM.
I would now like to debug on the M4 via a SEGGER Flasher ARM probe, still from Ubuntu.
My probe is well recognized by Ubuntu, and I can launch the J-Link GDB server by simply typing the command :
$ sudo ./JLinkGDBServerCLExe
However, if I type the same command without sudo, I get :
$ ./JLinkGDBServerCLExe
SEGGER J-Link GDB Server V7.58b Command Line Version
JLinkARM.dll V7.58b (DLL compiled Nov 16 2021 15:04:27)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: yes
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: Unspecified
Target interface: JTAG
Target interface speed: 4000kHz
Target endian: little
Connecting to J-Link...
Connecting to J-Link failed. Connected correctly?
GDBServer will be closed...
Shutting down...
Could not connect to J-Link.
Please check power, connection and settings.
My problem is that when I start eclipse, I get the same result as starting the GDB server without sudo.
It seems that this is a rights issue, how can I solve it?
As #KamilCuk said, the problem came from the udev rules.
So you just have to copy the rules provided by Segger with J-Link Software on the system:
$ sudo cp 99-jlink.rules /etc/udev/rules.d
Then you have to reboot the system:
$ reboot
My Linux server holding DPDK application got rebooted, once it came up. All the ports which were bonded to UIO_IGB got into a weird state. They are bounded to uio_pci_generic after reboot and unable to unbind those. Even with force.
I had to hard reset or complete power cycle to get those back normal.
Is there any way to handle this issue?
python dpdk-devbind.py --status
Other Network devices
=====================
0000:05:00.0 'Device 15ab' unused=uio_pci_generic
0000:05:00.1 'Device 15ab' unused=uio_pci_generic
# python dpdk-devbind.py -u 0000:05:00.0
0000:05:00.0 Device is not currently managed by any driver
# python dpdk-devbind.py --force -u 0000:05:00.0
0000:05:00.0 Device is not currently managed by any driver
#kaushik from the logs the device is not bound to any driver ixgbe or uio_pci_generic. You are better off either bind it back to kernel ixgbe driver or igb_uio, vfio-pci or uio_pci_generic.
Note: I have tried to explain this in the comments.
EDIT-1: based on the comments, the issue is resolved by recompiling igb_uio and forcing the firmware to be update for the driver make; make install; update-initramfs -u
The jetty on our linux server is not installed as a service as we have multiple jetty servers on different ports. And we use command./jetty.sh stop and ./jetty.sh start to stop and start jetty.
However, when I add sudo to the command, the server never stop/start successfully. When I run sudo ./jetty.sh stop, it shows
Stopping Jetty: start-stop-daemon: warning: failed to kill 18772: No such process
1 pids were not killed
No process in pidfile '/var/run/jetty.pid' found running; none killed.
and the server was not stopped.
When I run sudo ./jetty.sh start, it shows
Starting Jetty: FAILED Tue Apr 23 23:07:15 CST 2019
How could this happen? From my understanding. Using sudo gives you more power and privilege to run commands. If you can successfully execute without sudo, then the command should never fail with sudo, since it only grants superuser privilege.
As a user it uses $HOME.
As root it uses system paths.
The error you got ..
Stopping Jetty: start-stop-daemon: warning: failed to kill 18772: No such process
1 pids were not killed
No process in pidfile '/var/run/jetty.pid' found running; none killed.
... means that there was a bad pid file sitting around for a process that no longer exists.
Short answer, the processing is different if you are root (a service) vs a user (just an application).
I am trying to start my dockerd daemon by this command - dockerd &
Then i start getting the error as below -
ERRO[0036] libcontainerd: failed to receive event from containerd: rpc error: code = 12 desc = unknown service types.API
This keeps rolling again and again and i am unable to start any container after that. If i close the session and open a new session, i could see docker ps is accessible. But i am unable to start any container. While starting the container I am getting error -
docker run hello-world
docker: Error response from daemon: unknown service types.API. ERRO[0000] error waiting for container: context canceled
Please let me know if any logs are needed.
Why do you start the docker daemon using dockerd & and not systemctl start docker.service? This is probably the cause of your problem.
In order to start the daemon at boot, you need to run systemctl enable docker.service. See Getting Started with Containers.
Note that the kernel for Red Hat Enterprise Linux 6 only supports a limited subset of the functionality needed for container support, and I don't think anyone tests either the daemon or container images on that operating system version.
I have a debian linux image running on Google compute. Can successfully get cassandra working with "sudo cassandra" or "sudo cassandra -f" but then as soon as I log off this stops working. But when I try to run this as a service it simply doesnt say anything and doesnt start it either! I installed it using the aptget package v2.1.
I've tried sudo service cassandra start. It looks like its doing something and then quits without any logs.
Please help me run this up as a service. I can't even locate where the logs are stored when I run it as a service.
I ran into this issue recently, and as BrianC indicated it can be an out of memory condition. In my case I could successfully start cassandra with sudo cassandra -f but not with /etc/init.d/cassandra start.
For me, the last log entry in /var/log/cassandra/system.log when starting as a service was:
INFO [main] 2015-04-30 10:58:16,234 CassandraDaemon.java (line 248) Classpath: /etc/cassandra:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang3-3.1.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/disruptor-3.0.1.jar:/usr/share/cassandra/lib/guava-15.0.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jbcrypt-0.3m.jar:/usr/share/cassandra/lib/jline-1.0.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.9.1.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/lz4-1.2.0.jar:/usr/share/cassandra/lib/metrics-core-2.2.0.jar:/usr/share/cassandra/lib/netty-3.6.6.Final.jar:/usr/share/cassandra/lib/reporter-config-2.1.0.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.7.2.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.7.2.jar:/usr/share/cassandra/lib/snakeyaml-1.11.jar:/usr/share/cassandra/lib/snappy-java-1.0.5.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/lib/super-csv-2.1.0.jar:/usr/share/cassandra/lib/thrift-server-0.3.7.jar:/usr/share/cassandra/apache-cassandra-2.0.14.jar:/usr/share/cassandra/apache-cassandra-thrift-2.0.14.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/java/jna.jar::/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
And nothing afterwards. If it is a memory problem you should be able to verify this in your syslog. If if contains something like:
Apr 30 10:53:39 dev kernel: [1173246.957818] Out of memory: Kill process 8229 (java) score 132 or sacrifice child
Apr 30 10:53:39 dev kernel: [1173246.957831] Killed process 8229 (java) total-vm:634084kB, anon-rss:286772kB, file-rss:12676kB
Increase your ram. In my case I increased it to 2GB and it started fine.