Discussion:
forking PIDFile question
(too old to reply)
s***@goodey.org
2018-02-19 21:29:32 UTC
Permalink
Raw Message
Hello,

Sorry if this question is a bit basic for a devel list, I tried asking it in a ubuntu forum but
didn't get any views, let alone replies.

I have a PC running Mythbuntu which has an LCD which I had a bit of a struggle getting
going under systemd. However using Type=forking it is now working fine. However
reading the man page for systemd.service is says that it is recommended to use PIDFile. I
have tried adding PIDFile=/run/LCDd.pid but this causes an error message:-

LCDd.service - LCDd
Loaded: loaded (/etc/systemd/system/LCDd.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-02-13 09:49:03 GMT; 1min 8s ago
Process: 2485 ExecStart=/usr/sbin/LCDd -c /home/steve/lcd/LCDd.conf (code=exited,
status=0/SUCCESS)
CGroup: /system.slice/LCDd.service
└─2487 /usr/sbin/LCDd -c /home/steve/lcd/LCDd.conf

Feb 13 09:49:03 mythbuntu systemd[1]: Starting LCDd...
Feb 13 09:49:03 mythbuntu systemd[1]: LCDd.service: PID file /run/LCDd.pid not readable
(yet?) after start: No such file or directory
***@mythbuntu:~$

Removing the line PIDFile=/run/LCDd.pid in LCDd.service and all is good.
I have tried creating LCDd.pid in /run with root:root but get the same. How is the pid file
generated? Am I right in thinking that LCDd is so old that it hasn't been written with systemd
in mind so does not support PIDFile?



LCDd.service
[Unit]
Description=LCDd
After=multi-user.target

[Service]
Type=forking
PIDFile=/run/LCDd.pid
ExecStart=/usr/sbin/LCDd -c /home/steve/lcd/LCDd.conf
TimeoutStopSec=1s
Restart=on-failure
RestartSec=5
StartLimitInterval=30
StartLimitBurst=5

[Install]
WantedBy=multi-user.target


LCDd.conf
## This file was written by cme command.
## You can run 'cme edit lcdproc' to modify this file.
## You may also modify the content of this file with your favorite editor.


[server]
DriverPath=/home/steve/lcd/
Driver=vlsys_m428
NextScreenKey=Right
PrevScreenKey=Left
ReportToSyslog=yes
ToggleRotateKey=Enter
ServerScreen=no

Bind=127.0.0.1
Port=13666
User=nobody
Hello="Mythbuntu"
WaitTime=5

[menu]
DownKey=Down
EnterKey=Enter
MenuKey=Escape
UpKey=Up

[vlsys_m428]
Device=/dev/ttyUSB0

LCDd.conf (END)
--
Regards, Steve Goodey
Colchester, England
mailto://***@goodey.org
Registered Linux User #372670 http://counter.li.org
[1]
Hello to Jason Isaacs

--------
[1] 372670.png
Andrei Borzenkov
2018-02-20 04:30:06 UTC
Permalink
Raw Message
Post by s***@goodey.org
Hello,
Sorry if this question is a bit basic for a devel list, I tried asking it in a ubuntu forum but
didn't get any views, let alone replies.
I have a PC running Mythbuntu which has an LCD which I had a bit of a struggle getting
going under systemd. However using Type=forking it is now working fine. However
reading the man page for systemd.service is says that it is recommended to use PIDFile. I
have tried adding PIDFile=/run/LCDd.pid but this causes an error message:-
LCDd.service - LCDd
Loaded: loaded (/etc/systemd/system/LCDd.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-02-13 09:49:03 GMT; 1min 8s ago
Process: 2485 ExecStart=/usr/sbin/LCDd -c /home/steve/lcd/LCDd.conf (code=exited,
status=0/SUCCESS)
CGroup: /system.slice/LCDd.service
└─2487 /usr/sbin/LCDd -c /home/steve/lcd/LCDd.conf
Feb 13 09:49:03 mythbuntu systemd[1]: Starting LCDd...
Feb 13 09:49:03 mythbuntu systemd[1]: LCDd.service: PID file /run/LCDd.pid not readable
(yet?) after start: No such file or directory
Removing the line PIDFile=/run/LCDd.pid in LCDd.service and all is good.
I have tried creating LCDd.pid in /run with root:root but get the same. How is the pid file
generated?
It is expected to be written by your service binary. Ideally it should
do it only after it has completed initialization and is ready to provide
services.
Post by s***@goodey.org
Am I right in thinking that LCDd is so old that it hasn't been written with systemd
in mind so does not support PIDFile?
PID files predate systemd.
Mantas Mikulėnas
2018-02-20 06:32:45 UTC
Permalink
Raw Message
Post by s***@goodey.org
Hello,
Sorry if this question is a bit basic for a devel list, I tried asking it
in a ubuntu forum but didn't get any views, let alone replies.
I have a PC running Mythbuntu which has an LCD which I had a bit of a
struggle getting going under systemd. However using Type=forking it is now
working fine. However reading the man page for systemd.service is says that
it is recommended to use PIDFile.
It might be recommended in some cases (the more complex the daemon is), but
useless in your case.

Removing the line PIDFile=/run/LCDd.pid in LCDd.service and all is good.
Post by s***@goodey.org
I have tried creating LCDd.pid in /run with root:root but get the same.
How is the pid file generated?
It is created by your daemon process.

If your daemon does not support creating pidfiles, just don't use the
PIDFile= option in the first place...
Post by s***@goodey.org
Am I right in thinking that LCDd is so old that it hasn't been written
with systemd in mind so does not support PIDFile?
No; it's almost the opposite. Pidfiles have been in use for several decades
with sysvinit (they were one of the primary methods of service
identification), but became practically optional with systemd's
cgroup-based tracking.
--
Mantas Mikulėnas
Jonathan de Boyne Pollard
2018-02-21 06:31:23 UTC
Permalink
Raw Message
Post by s***@goodey.org
[Service]
Type=forking
Your program has an -f option to stop it from vainly trying to
re-daemonize itself. Use it; and do not use Type=forking in the first
place.

*
http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html#DoNotBackgroundise

The supplied systemd service unit that comes packaged by Ubuntu/Debian
does this. You can ignore its use of -s 1 , as systemd will log the
program's standard output and -s 0 will do quite well.

*
https://sources.debian.org/src/lcdproc/0.5.9-2/debian/lcdproc.LCDd.service/
Post by s***@goodey.org
[server]
User=nobody
Also, do not abuse nobody for dæmons. Use a dedicated unprivileged user
account, such as (for example) lcdproc. Name the unprivileged user
account in the service unit in a User= setting, and using filesystem
ACLs or otherwise grant it nothing except the permission to open
/dev/ttyUSB0 for writing and to open the configuration file for reading.

* http://jdebp.eu./FGA/dont-abuse-nobody-for-daemons.html

Currently, you are running your program as the superuser with a
configuration file owned by an unprivileged user. This is a backdoor
into your system, as anyone who compromises that unprivileged user
account (which is the one that you run your WWW browser as, and that you
use to run software build systems and other programs downloaded from
other people that you do not know, ne?) can rewrite the configuration
file and thereby persuade a superuser-privileged process to open an
arbitrary file and write stuff (which it does before it attempts to
detect whether it is running as the superuser).
s***@goodey.org
2018-02-21 15:23:37 UTC
Permalink
Raw Message
Post by Andrei Borzenkov
It is expected to be written by your service binary. Ideally it should
do it only after it has completed initialization and is ready to provide
services.
Post by s***@goodey.org
Am I right in thinking that LCDd is so old that it hasn't been written
with systemd in mind so does not support PIDFile?
PID files predate systemd.
Thanks for your comments.


Regards, Steve Goodey
Colchester, England
mailto://***@goodey.org
Registered Linux User #372670 http://counter.li.org

Hello to Jason Isaacs
s***@goodey.org
2018-02-21 15:24:40 UTC
Permalink
Raw Message
Post by Mantas Mikulėnas
Post by s***@goodey.org
Hello,
Sorry if this question is a bit basic for a devel list, I tried asking it
in a ubuntu forum but didn't get any views, let alone replies.
I have a PC running Mythbuntu which has an LCD which I had a bit of a
struggle getting going under systemd. However using Type=forking it is now
working fine. However reading the man page for systemd.service is says
that
it is recommended to use PIDFile.
It might be recommended in some cases (the more complex the daemon is), but
useless in your case.
Removing the line PIDFile=/run/LCDd.pid in LCDd.service and all is good.
Post by s***@goodey.org
I have tried creating LCDd.pid in /run with root:root but get the same.
How is the pid file generated?
It is created by your daemon process.
If your daemon does not support creating pidfiles, just don't use the
PIDFile= option in the first place...
Post by s***@goodey.org
Am I right in thinking that LCDd is so old that it hasn't been written
with systemd in mind so does not support PIDFile?
No; it's almost the opposite. Pidfiles have been in use for several decades
with sysvinit (they were one of the primary methods of service
identification), but became practically optional with systemd's
cgroup-based tracking.
Thanks for your comments.


Regards, Steve Goodey
Colchester, England
mailto://***@goodey.org
Registered Linux User #372670 http://counter.li.org

Hello to Jason Isaacs
s***@goodey.org
2018-02-21 15:25:10 UTC
Permalink
Raw Message
Post by Jonathan de Boyne Pollard
Post by s***@goodey.org
[Service]
Type=forking
Your program has an -f option to stop it from vainly trying to
re-daemonize itself. Use it; and do not use Type=forking in the first
place.
*
http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html#DoNotBackgrou
ndise
The supplied systemd service unit that comes packaged by Ubuntu/Debian
does this. You can ignore its use of -s 1 , as systemd will log the
program's standard output and -s 0 will do quite well.
*
https://sources.debian.org/src/lcdproc/0.5.9-2/debian/lcdproc.LCDd.service/
Post by s***@goodey.org
[server]
User=nobody
Also, do not abuse nobody for dæmons. Use a dedicated unprivileged user
account, such as (for example) lcdproc. Name the unprivileged user
account in the service unit in a User= setting, and using filesystem
ACLs or otherwise grant it nothing except the permission to open
/dev/ttyUSB0 for writing and to open the configuration file for reading.
* http://jdebp.eu./FGA/dont-abuse-nobody-for-daemons.html
Currently, you are running your program as the superuser with a
configuration file owned by an unprivileged user. This is a backdoor
into your system, as anyone who compromises that unprivileged user
account (which is the one that you run your WWW browser as, and that you
use to run software build systems and other programs downloaded from
other people that you do not know, ne?) can rewrite the configuration
file and thereby persuade a superuser-privileged process to open an
arbitrary file and write stuff (which it does before it attempts to
detect whether it is running as the superuser).
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Thanks very much Jonathan for your help and in looking through the conf files and pointing
out my mistakes. I have altered them as per your instructions and all is now running fine.

Thanks to all who replied and my apologies if my little problem has cluttered up your list :-)


Regards, Steve Goodey
Colchester, England
mailto://***@goodey.org
Registered Linux User #372670 http://counter.li.org

Hello to Jason Isaacs

Loading...