Procd creates /dev/tty0 to /dev/ttyzf

I have a problem on my OpenWRT image.
Something is creating a huge amount of software tty's using procd:

[   54.791490] procd: Command: makedev
[   54.795068] procd:  /dev/ttyx6
[   54.798175] procd:  0660
[   54.800958] procd:  dialout
[   54.803818] procd: Message:
[   54.806655] procd:  ACTION=add
[   54.809751] procd:  DEVPATH=/devices/virtual/tty/ttyx6
[   54.815070] procd:  SUBSYSTEM=tty
[   54.818443] procd:  SYNTH_UUID=0
[   54.821838] procd:  MAJOR=3
[   54.824691] procd:  MINOR=134
[   54.827705] procd:  DEVNAME=ttyx6
[   54.831178] procd:  SEQNUM=1744
[   54.834684] procd: Command: makedev
[   54.838247] procd:  /dev/ttyx6
[   54.841549] procd:  0600
[   54.844149] procd: Message:
[   54.846992] procd:  ACTION=add
[   54.850231] procd:  DEVPATH=/devices/virtual/tty/ttyx6
[   54.855423] procd:  SUBSYSTEM=tty
[   54.858777] procd:  SYNTH_UUID=0
[   54.862171] procd:  MAJOR=3
[   54.865020] procd:  MINOR=134
[   54.868030] procd:  DEVNAME=ttyx6
[   54.871498] procd:  SEQNUM=1744

This ranges from tty0, ttyf, ... , tty10, ... , tty1f, ... , ttyzf thus having a crazy amount (34*16) tty. The same with pty.
As far as I was able to debug this, the origin of this behavior is /dev/hotplug.json:

"add": [
                        [ "if",
                                [ "and",
                                        [ "has", "MAJOR" ],
                                        [ "has", "MINOR" ]
                                        [ "if",
                                                [ "eq", "DEVNAME",
                                                        [ "null", "full", "ptmx", "zero", "tty", "net", "random", "urandom" ]
                                                        [ "makedev", "/dev/%DEVNAME%", "0666" ],
                                                        [ "return" ]
                                        [ "if",
                                                [ "regex", "DEVNAME", "^snd" ],
                                                [ "makedev", "/dev/%DEVNAME%", "0660", "audio" ]
                                        [ "if",
                                                [ "regex", "DEVNAME", "^tty" ],
                                                [ "makedev", "/dev/%DEVNAME%", "0660", "dialout" ]
                                        [ "if",
                                                [ "has", "DEVNAME" ],
                                                [ "makedev", "/dev/%DEVNAME%", "0600" ]
                        [ "if",
                                [ "has", "FIRMWARE" ],
                                        [ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ],
                                        [ "load-firmware", "/lib/firmware" ],
                                        [ "return" ]
                        [ "if",
                                [ "regex", "DEVNAME", "^ttyGS" ],
                                [ "start-console", "%DEVNAME%" ]

But if I remove the corresponding entry, the console stops working.

Is there any way to stop hotplug.json spamming this much ttys? It delays the init of netifd by up to 5 seconds!
Im using the mainline openwrt.

1 Like

Which specific device, or is this related to your board that requires your own, custom SPI-NAND driver?

Its an LicheePI (Allwinner V3s). I already dig down in every sunxi-related files. As much as I found, its unrelated to sunxi and must come from mainline openwrt.

I observed this behavior from the start and I double checked: Fresh git clone (github daed78ab55b135235a106b4b75bf3b650f81786e), selected the target, run make, flashed it on the SD-Card and booted it up.
No special spi-nand drivers, nothing, really. Just plain mainline openwrt with the licheepi-target selected.

What you're seeing isn't "normal", so I suspect something about the device or the port to the device.

From a couple of other routers

$ ls /dev/tty*
/dev/tty      /dev/ttyMSM0  /dev/ttyS0    /dev/ttyS1
$ ls /dev/tty*
/dev/tty    /dev/ttyS0
# ls /dev/tty*
/dev/tty     /dev/ttyS1   /dev/ttyS11  /dev/ttyS13  /dev/ttyS15  /dev/ttyS3   /dev/ttyS5   /dev/ttyS7   /dev/ttyS9
/dev/ttyS0   /dev/ttyS10  /dev/ttyS12  /dev/ttyS14  /dev/ttyS2   /dev/ttyS4   /dev/ttyS6   /dev/ttyS8

I don't know if this are good or bad news.

Where does the hotplug.json service (which service parses this file?) take its "hotplug" events from? I would assume thats the culprit. I can't find any info which services takes care of this functionality. So I can't debug this deeper.

Just to chime in: I see the same issue with an Oxnas target (Pogoplug V3), hundreds of tty/pty devices created. The issue seems to be benign, but it's not very pretty. Tested on both current snapshot and 19.07.0-rc2.

Could be related to kernel configuration options. I suspect


I don't think we need those legacy PTYs and once we remove that kernel option (or at least reduce them to a reasonable number, eg. at91 target current got 4 instead of 256), hotplug will no longer be triggered to create all those unneeded device nodes.
This probably happened because everybody copied the existing kernel configuration of an existing target (I suspect kirkwood) to create new targets and it's set there as well (and on ixp4xx, layerscape, malta, mpc85xx, mxs, oxnas, sunxi and uml).
Another potentially related suspicious kernel config is


which should also not be required and may cause this kind of havoc.
Apparently it's set on at91, bcm2708, gemini, layerscape, malta, oxnas, samsung, sunxi, x86 and zynq. On targets with framebuffer it may actually be justified (ie. bcm2708, samsung, sunxi and x86), but on headless devices this should also not be needed.

Can someone with the hardware at hand try to simply remove those lines from target//config and see if the resulting image still works and fixes the problem?


Bang on. Disabling those two options results in a huge improvement:

root@OpenWrt:/# ls /dev
bus                 ram14               tty39
console             ram15               tty4
cpu_dma_latency     ram2                tty40
full                ram3                tty41
gpiochip0           ram4                tty42
gpiochip1           ram5                tty43
kmsg                ram6                tty44
log                 ram7                tty45
loop-control        ram8                tty46
loop0               ram9                tty47
loop1               random              tty48
loop2               shm                 tty49
loop3               tty                 tty5
loop4               tty0                tty50
loop5               tty1                tty51
loop6               tty10               tty52
loop7               tty11               tty53
memory_bandwidth    tty12               tty54
mtd0                tty13               tty55
mtd0ro              tty14               tty56
mtd1                tty15               tty57
mtd1ro              tty16               tty58
mtd2                tty17               tty59
mtd2ro              tty18               tty6
mtd3                tty19               tty60
mtd3ro              tty2                tty61
mtd4                tty20               tty62
mtd4ro              tty21               tty63
mtdblock0           tty22               tty7
mtdblock1           tty23               tty8
mtdblock2           tty24               tty9
mtdblock3           tty25               ttyS0
mtdblock4           tty26               ttyS1
network_latency     tty27               ttyS2
network_throughput  tty28               ttyS3
null                tty29               ubi0
port                tty3                ubi0_0
ptmx                tty30               ubi0_1
ptp0                tty31               ubi_ctrl
pts                 tty32               ubiblock0_0
ram0                tty33               urandom
ram1                tty34               vcs
ram10               tty35               vcs1
ram11               tty36               vcsa
ram12               tty37               vcsa1
ram13               tty38               zero

64 tty devices still seems unnecessarily high, but I didn't remove CONFIG_VT_CONSOLE yet -- maybe it's responsible for those. But it's already a far cry from, literally, more than a thousand tty/pty devices.

(IMHO, this issue should probably be evaluated and corrected for the respective targets, ASAP, before 19.07 ships.)


I've cleaned things up in master branch, once it has seen some testing we should backport to 19.07 asap.


I am happy to report that the new snapshot (removed both the CONFIG_LEGACY_PTYS and CONFIG_VT options as per this commit by @daniel which he also did for various other targets) resulted in the IMHO correct amount of ttys/ptys:

root@OpenWrt:/# ls /dev/tty*
/dev/tty     /dev/ttyS10  /dev/ttyS13  /dev/ttyS2   /dev/ttyS5   /dev/ttyS8
/dev/ttyS0   /dev/ttyS11  /dev/ttyS14  /dev/ttyS3   /dev/ttyS6   /dev/ttyS9
/dev/ttyS1   /dev/ttyS12  /dev/ttyS15  /dev/ttyS4   /dev/ttyS7
root@OpenWrt:/# ls /dev/pty*
ls: /dev/pty*: No such file or directory

(Tested on Oxnas/Pogoplug V3)

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.