The qpage application is invoked as root during boot, but relinquishes root rights, running as daemon. Based on my entries in /etc/qpage/qpage.cf the application will require access to /dev/ttyS1, however at boot time /dev/ttyS1 is set mod 660 and is owned by root:uucp. Apparently qpage must not open ttyS1 before giving up rights, and so I see errors in /var/log/daemon.log and qpage fails to start. Chmod'ing /dev/ttyS1 to mode 666 will allow me to start qpage manually (/etc/init.d/qpage start). Reproducible: Always Steps to Reproduce: 1. boot system, see qpage fail and note contents of /var/log/daemon.log 2. /etc/init.d/qpage start (application still won't start... same msgs) 3. chmod 666 /dev/ttyS1 4. /etc/init.d/qpage start (application now starts fine) Expected Results: qpage should be able to start at boot time. Perhaps qpage needs to open /dev/ttyS1 before giving up root access? or is there a system config which needs to be added to the qpage installation so that the rights to /dev/ttyS1 are set correctly? (This 2nd option seems not as desirable, given that the user (me) might choose to use a different device later on....)
========================================================== ========================================================== ========================================================== Partial contents of /etc/qpage/qpage.cf ======= queuedir=/var/spool/qpage lockdir=/var/lock/subsys/qpage identtimeout=5 snpptimeout=60 modem=ModemNo9 # was device=/dev/tts/1 device=/dev/ttyS1 dialcmd=ATDT service=NRMpage01 device=ModemNo9 phone=5-4149 baudrate=1200 maxmsgsize=200 pager=test01 pagerid=John.Doe service=NRMpage01 ========================================================== ========================================================== ========================================================== Partial contents of /var/log/daemon.log ======= Oct 29 08:38:25 gluon qpage[5502]: /etc/qpage/qpage.cf(72): cannot access /dev/tts/1: Permission denied Oct 29 08:38:25 gluon qpage[5502]: /etc/qpage/qpage.cf(74): no device for modem=ttyS0 Oct 29 08:38:25 gluon qpage[5502]: /etc/qpage/qpage.cf(75): cannot access /dev/tts/1: Permission denied Oct 29 08:38:25 gluon qpage[5502]: /etc/qpage/qpage.cf(78): no device for modem=ttyS1 Oct 29 08:38:25 gluon qpage[5502]: /etc/qpage/qpage.cf(79): cannot access /dev/tts/1: Permission denied Oct 29 08:38:25 gluon qpage[5502]: /etc/qpage/qpage.cf(82): no device for modem=ModemDial9 Oct 29 08:38:25 gluon qpage[5502]: /etc/qpage/qpage.cf(83): cannot access /dev/tts/1: Permission denied Oct 29 08:38:25 gluon qpage[5502]: /etc/qpage/qpage.cf(86): no device for modem=ModemNo9 Oct 29 09:01:25 gluon rc-scripts: WARNING: qpage has not yet been started. Oct 29 09:01:36 gluon qpage[6336]: /etc/qpage/qpage.cf(73): cannot access /dev/ttyS1: Permission denied Oct 29 09:01:36 gluon qpage[6336]: /etc/qpage/qpage.cf(75): no device for modem=ttyS0 Oct 29 09:01:36 gluon qpage[6336]: /etc/qpage/qpage.cf(76): cannot access /dev/ttyS1: Permission denied Oct 29 09:01:36 gluon qpage[6336]: /etc/qpage/qpage.cf(79): no device for modem=ttyS1 Oct 29 09:01:36 gluon qpage[6336]: /etc/qpage/qpage.cf(80): cannot access /dev/ttyS1: Permission denied Oct 29 09:01:36 gluon qpage[6336]: /etc/qpage/qpage.cf(83): no device for modem=ModemDial9 Oct 29 09:01:36 gluon qpage[6336]: /etc/qpage/qpage.cf(84): cannot access /dev/ttyS1: Permission denied Oct 29 09:01:36 gluon qpage[6336]: /etc/qpage/qpage.cf(87): no device for modem=ModemNo9
To add your user(s) to a group that has the needed permissions, as the pkg_postinst message already told you: <snip> elog "2. Insure that the serial port selected in qpage.cf" elog " is writable by user or group daemon." </snip>
udevd resets ownership and mode of everything in /dev. Are you saying that the only solution is to modify 50-udev.rules from 50-udev.rules:KERNEL=="ttyS[0-9]*", NAME="%k", SYMLINK="tts/%n", GROUP="uucp", MODE="0660" to 50-udev.rules:KERNEL=="ttyS[0-9]*", NAME="%k", SYMLINK="tts/%n", GROUP="uucp", MODE="0660" 50-udev.rules:KERNEL=="ttyS1", NAME="%k", SYMLINK="tts/%n", GROUP="daemon", MODE="0660"
(In reply to comment #3) > udevd resets ownership and mode of everything in /dev. Are you saying that the > only solution is to modify 50-udev.rules from No, the solution is to add yourself to a group that has needed privs to /dev/ttyS? (such as uucp).
OK, this is embarassing. The first thing, in fact, that I tried was to add user daemon to group uucp... but I did it backwards... added group uucp to user daemon. That didn't work (no suprise there) and so I opened the bug. <thump> <thump> <thump> <thump> <thump> <thump> <thump> OK, I've stopped hitting my head on my desk, CORRRECTLY modified /etc/group, and all is well. Thanks for your patience.
