Cannot delete device /dev/pps0

petejc · 05-31-2020, 01:32 PM

I have been playing with gpsd and ntpd. I was trying to figure out if my usb gps device had a pulse per second output, it did not. I used ldattach 18 /dev/ttyACM0 (or a very similar device which was my usb gps) to create /dev/pps0. Now, despite the usb gps being unplugged and rebooting, /dev/pps0 remains. I have not got any rules for it in /ete/udev/rules.d etc nor anything in rc.local which creates it. I can't see how to get rid of it.

I want rid of it as it may be confusing things now I have a usb gps with working PPS that I want to connect.

Just doing this for fun, because I can.

abga · 05-31-2020, 03:27 PM

Is ldattach launched automatically / running? Kill it.
Check if you have some pps* modules loading, unload them.
If still not able to get rid of it, check if/who's using it (process):

Code:

/usr/bin/fuser /dev/pps0

This will output a PID (or some). Look either with:

Code:

ps ax | grep PID | grep -v grep
#or in 
/proc/PID/cmdline

after the process(es) - substitute PID with the actual PID!

petejc · 05-31-2020, 06:10 PM

Quote:

Originally Posted by abga

Is ldattach launched automatically / running? Kill it.
Check if you have some pps* modules loading, unload them.
If still not able to get rid of it, check if/who's using it (process):

Code:

/usr/bin/fuser /dev/pps0

This will output a PID (or some). Look either with:

Code:

ps ax | grep PID | grep -v grep
#or in 
/proc/PID/cmdline

after the process(es) - substitute PID with the actual PID!

No luck. Rebooted without GPS starting on boot, no gps devices plugged in:

Code:

root@phoenix:~# lsmod | grep pps
root@phoenix:~#

No modules loaded. But this kernel was built with pps as modules:

Code:

root@phoenix:~# ls /lib/modules/5.6.13/kernel/drivers/pps/clients/   
pps-gpio.ko  pps-ldisc.ko  pps_parport.ko

Nothing:

Code:

root@phoenix:~# /usr/bin/fuser /dev/pps0
root@phoenix:~#

petejc · 05-31-2020, 06:11 PM

Of couse, it is still there:

Code:

root@phoenix:~# ls -al /dev/pps0 
crw------- 1 root root 249, 0 Jun  1 00:03 /dev/pps0

abga · 05-31-2020, 07:23 PM

Quote:

Originally Posted by petejc

Of couse, it is still there:

Code:

root@phoenix:~# ls -al /dev/pps0 
crw------- 1 root root 249, 0 Jun  1 00:03 /dev/pps0

That looks like normal character file, presumably created "mknod style" by ldattach and it should be removable.
The ldattach man states that it should get removed once the ldattach process ends. Don't know why it's still there:

Quote:

- snippet from man ldattach
In order to detach the line discipline, kill(1) the ldattach process.

Could you please provide the output of:

Code:

grep 249 /proc/devices

just to see which driver has the major 249.

petejc · 06-01-2020, 11:22 AM

Quote:

Originally Posted by abga

That looks like normal character file, presumably created "mknod style" by ldattach and it should be removable.
The ldattach man states that it should get removed once the ldattach process ends. Don't know why it's still there:

Could you please provide the output of:

Code:

grep 249 /proc/devices

just to see which driver has the major 249.

OK

Code:

bash-4.3$ grep 249 /proc/devices
249 pps

I've plugged a gps device I am testing in, perhaps I should remove it? I did find a normal rm would delete /dev/pps0. However, it would reappear by magic on reboot even though I did not run ldattach. Further, if I delete /dev/pps0, as it is not being used, and then run ldattach having plugged in a suitable gps, I get /dev/pps1 not /dev/pps0.

Having deleted /dev/pps0 grepping /proc/devices has the same result.

The issue is that /dev/pps0 reappears on rebooting for no reason I can see, e.g. no GSP device plugged in, no gpsd, nothing in rc.local or modules inserted.

abga · 06-01-2020, 02:52 PM

I thought it's a stale node, left over by an ungraceful exit of ldattach and that you cannot delete it - permission denied.
It turns out it is used by the pps driver and udev is creating it at startup, presumably because it loads the pps driver (can check it with "dmesg | grep pps") for the plugged gps device.
Yes, you should try removing the gps device, unload all pps drivers, delete the /dev/pps0 and check if/what udev stores in /etc/udev/hwdb.d and /etc/udev/devices
If you find there some related records, delete (backup them). Then, before restarting the system, flush the udev running database:

Code:

/sbin/udevadm info --cleanup-db
# and force it to refresh it
/sbin/udevadm control --reload-rules
/sbin/udevadm trigger

After these steps, check if you got the /dev/pps0 back and if negative, go for a restart - check again if it creates it at start-up.

Some helpful info:
https://www.freedesktop.org/software...n/udevadm.html
https://www.freedesktop.org/software.../man/hwdb.html

bassmadrigal · 06-01-2020, 03:56 PM

I wanted to mention that /dev/pps0 exists on my 14.2 system and I've never hooked up a GPS or done any of the other things you've mentioned (however, it doesn't exist on my -current system that hasn't been upgraded for about a year). I suppose I did something over the course of the several years I've had the machine up and running to get it to populate, but if I did, it was unintentional.

If you're running 14.2, it's possible that /dev/pps0 being available is the default.

abga · 06-01-2020, 04:45 PM

@bassmadrigal

Just checked on the available systems:
- 2 Intel (x86) laptops running an up-to-date Slackware 14.2 - no /dev/pps*
- 1 Raspberry Pi Zero running an up-to-date Slackware ARM 14.2 - no /dev/pps*
- 1 Raspberry Pi 2B running an up-to-date Slackware ARM -current - no /dev/pps*

I didn't play with any modems/serial devices on these systems.

bassmadrigal · 06-01-2020, 06:47 PM

Interesting! I've never had a modem/serial devices hooked up to any of my computers (definitely never used ldattach or modprobed the pps module. I wonder what caused it to pop on mine... not enough to try and figure out how to get rid of it, but just curious.

abga · 06-01-2020, 07:11 PM

I also have no experience (not that I remember) with ldattach and as mentioned in #7 I thought /dev/pps0 is a stale node entry (leftover). It should be udev remembering its state and re-creating it at boot / or when it loads the pps* modules. AFAIK, udev only stores persistent stuff in /etc/udev/hwdb.d and /etc/udev/devices, plus the user defined rules.

Had a look over the source code of ldattach (not that I'm a good C coder), learned that it only temporarily registers the line discipline, exactly how documented, meaning /dev/pps0 should be gone after ldattach exits. But then, I noticed some ioctl calls in the source code and I closed the tab immediately

https://github.com/karelzak/util-lin...ils/ldattach.c
Mr. Karel Zak should know better how it works...
https://github.com/karelzak/util-linux

petejc · 06-02-2020, 04:15 PM

Quote:

Originally Posted by abga

I thought it's a stale node, left over by an ungraceful exit of ldattach and that you cannot delete it - permission denied.
It turns out it is used by the pps driver and udev is creating it at startup, presumably because it loads the pps driver (can check it with "dmesg | grep pps") for the plugged gps device.
Yes, you should try removing the gps device, unload all pps drivers, delete the /dev/pps0 and check if/what udev stores in /etc/udev/hwdb.d and /etc/udev/devices
If you find there some related records, delete (backup them). Then, before restarting the system, flush the udev running database:

Code:

/sbin/udevadm info --cleanup-db
# and force it to refresh it
/sbin/udevadm control --reload-rules
/sbin/udevadm trigger

After these steps, check if you got the /dev/pps0 back and if negative, go for a restart - check again if it creates it at start-up.

Some helpful info:
https://www.freedesktop.org/software...n/udevadm.html
https://www.freedesktop.org/software.../man/hwdb.html

Thank you. I've avoided playing with udev unless essential. None of what you suggested fixed anything. However, this, and perhaps another message here got me to grep dmesg and I think ptp, precision time protocol, may be involved:

Code:

[    0.416388] usbcore: registered new interface driver usbfs
[    0.416533] usbcore: registered new interface driver hub
[    0.416533] usbcore: registered new device driver usb
[    0.416533] pps_core: LinuxPPS API ver. 1 registered
[    0.416553] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.416780] PTP clock support registered

and:

Code:

[    7.745201] cfg80211: failed to load regulatory.db
[    7.769656] pps pps0: new PPS source ptp0
[    7.769848] igb 0000:06:00.0: added PHC on eth0
[    7.770007] igb 0000:06:00.0: Intel(R) Gigabit Ethernet Network Connection

I note that the root file system mounted at 7.448 seconds. So the messaged before this cannot be influenced by and config or udev.

I suspect that when I built a recent kernel, checking for pps support I saw the option for ptp and though I might enable that. Usually enabling extra stuff does little harm. I believe my next step is to build a kernel without ptp to see if I loose the pps0 and see if it fixes the problems I have getting pps through to ntpd.

abga · 06-02-2020, 05:25 PM

Well, I failed to realize that you're actually running a custom kernel and focused only on the stock Slackware kernel instead.
You mentioned in #3

Quote:

But this kernel was built with pps as modules:

and I thought you're referring to the stock kernel, didn't verify it

Your suspicion might be right, AFAIK only udev could keep some settings persistent through reboots and if that one is clean, then it's only the driver you enabled creating /dev/pps0 automatically. Your dmesg snippet also confirms that.

Some time ago I also considered buying a cheap GPS receiver, hook it on A Raspberry Pi Zero and set it as an accurate timeserver in my local LAN. But then learned that I could actually use DVB-S2 (satellite) timestamps instead (I own and use such a DVB-S2 USB receiver) and that it provides almost "atomic clock accuracy":
https://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps
https://linuxtv.org/hg/dvb-apps/file/tip/util/dvbdate
https://manpages.debian.org/jessie/d...date.1.en.html

abga · 06-02-2020, 05:56 PM

From this rather old doc:
http://paul.chavent.free.fr/pps.html
- it looks like pps-ktimer is creating /dev/pps0
Had a look in the source of an actual kernel 4.x and found: /drivers/pps/clients/Kconfig

Quote:

config PPS_CLIENT_KTIMER
tristate "Kernel timer client (Testing client, use for debug)"
help
If you say yes here you get support for a PPS debugging client
which uses a kernel timer to generate the PPS signal.

This driver can also be built as a module. If so, the module
will be called pps-ktimer.

Looking back to your post #3, I believe you got this one compiled in-kernel instead of module and the kernel loads it automatically at boot, creating /dev/pps0. That's my theory

bassmadrigal · 06-02-2020, 06:14 PM

I will say that my 14.2 install is running a custom 5.4.30 kernel, but it is very close to Pat's 5.4.30 generic kernel config (took his config and set an AMD processor type and removed a few old things like pcmcia and parallel port support).