Description of problem: gpsd.service starts on boot even if it is disabled. It attaches itself to /dev/ttyUSB0 and when rigctld.service starts there are two services using the same USB port which causes the rigctld service to fail horribly with long delays and communication failures. Killing the gpsd process instantly clears the problems with rigctld. This is a desktop so there is no use for gpsd at all. I have been trying to diagnose this issue in Mga8 and cauldron which only appears to happen with my user and /home. What, if it is in my user settings, could be the cause of this? D.E. is plasma. I would un-install the package, but it would take plasma-workspace etc. with it. How reproducible: Varies, the presence of gpsd also connected to /dev/ttyUSB0 in systems without my /home seem to work, however when my /home is there then only killing gpsd cures the issue. I admit to being out of my depth with this. I will try using a different D.E. to see if it maybe relates only to plasma. Steps to Reproduce: 1. 2. 3.
OK that is interesting. Running under IceWM, the gpsd.service does start, but does not connect to /dev/tty/USB0. [root@localhost baz]# lsof /dev/ttyUSB0 lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rigctld 2533 root 3u CHR 188,0 0t0 1034 /dev/ttyUSB0 rigctld.service starts at boot and works perfectly. Something in plasma is connecting gpsd to /dev/tty/USB0 on boot when my user settings in /home are available.
Leaving this with you for the moment, Barry, since you are good at pinning things down (like comment 1). Surprised to find that my system has gpsd, but it is correctly shown as not running, and not to auto-start. (In reply to Barry Jackson from comment #1) > Running under IceWM, the gpsd.service does start, but does not connect to > /dev/tty/USB0. > Something in plasma is connecting gpsd to /dev/tty/USB0 on boot when my user > settings in /home are available. My guess is that you have an application installed, and present somewhere in your HOME, which Plasma takes note of; but not IceWM. And what causes gpsd to be started anyway? (In reply to Barry Jackson from comment #0) > I would un-install the package, but it would take plasma-workspace etc. with > it. So it seems! $ sudo urpme --test gpsd To satisfy dependencies, the following 6 packages will be removed (65MB): gpsd-3.25-1.mga9.x86_64 konq-plugins-23.04.1-1.mga9.x86_64 (oherwydd konqueror coll) konqueror-23.04.1-1.mga9.x86_64 (oherwydd plasma-workspace coll) plasma-workspace-5.27.5-2.mga9.x86_64 (oherwydd gpsd coll) plasma-workspace-wayland-5.27.5-2.mga9.x86_64 (oherwydd libkrdb.so()(64bit) coll, plasma-workspace == 5.27.5-2.mga9 heb ei foddloni) task-plasma5-minimal-5.27.5-2.mga9.noarch (oherwydd plasma-workspace coll) I suppose one could try rpm -e --nodeps ... What does MCC-System-Manage system services-Manage system services have to say about gpsd? In particular, is it shown to start automatically? And if you disable that?
CC: (none) => lewyssmith
>What does MCC-System-Manage system services-Manage system services have to say >about gpsd? In particular, is it shown to start automatically? And if you >disable that? It's set to not start on boot and I have disabled the service manually and stopped it with systemctl, but next boot the service is still disabled but running :( I will keep digging. Thanks ;)
/etc/sysconfig/gpsd has: # Set to 'true' to add USB devices automatically via udev USBAUTO="true" Changing this to "false" fixes the issue for me in plasma5, but I need to find out why udev thinks that my radio interface cable is a gps device!
Device is: 10c4:ea60 Silicon Labs CP210x UART Bridge.
/usr/lib/udev/rules.d/99-gpsd.rules contains the above device.
Something in plasma must be trying to access /usr/lib/systemd/system/gpsd.socket Digging through the systemsettings5 may help. Workarounds include "rpm -e --nodeps gpsd" which may cause problems in plasma, or "systemctl --now mask gpsd.service" and "systemctl --now mask gpsd.socket" both run as root.
CC: (none) => davidwhodgins
(In reply to Barry Jackson from comment #3) > It's set to not start on boot and I have disabled the service manually and > stopped it with systemctl, but next boot the service is still disabled but > running :( This is clearly wrong. Comment 1 points the finger of suspicion at Plasma. Sigh. However, comments 4/5/6 suggest that udev may also be at fault. Assigning to KDE for the first, CC'ing Thomas for the latter.
Assignee: bugsquad => kdeCC: lewyssmith => tmb
Removing the workaround in #4 and applying the masks in #7 (thanks Dave!) the services after boot are dead :) [root@localhost baz]# systemctl status gpsd ○ gpsd.service Loaded: masked (Reason: Unit gpsd.service is masked.) Active: inactive (dead) [root@localhost baz]# [root@localhost baz]# systemctl status gpsd.socket ○ gpsd.socket Loaded: masked (Reason: Unit gpsd.socket is masked.) Active: inactive (dead) [root@localhost baz]# I think the fact that these devices may be used in many different applications with different hardware makes writing meaningful udev rules very tricky. I am using this device to connect to radio equipment controlled via hamlib for use by several different programs, freedv, klog and wsjtx which all talk to hamlib (rigctld) using sockets. All works fine in clean systems or with new users. This issue seems to come from 'something' in my old user settings probably related to plasma/kde and as such I think that with two working workarounds available we can close this now as WFM as it's obviously a corner case. It did have me baffled, but there is no point wasting more time on it. Feel free to close.
Closing then.
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME