On 5/23/22 09:37, Florian Feldbauer via Tech-talk wrote:
Hey Maurizio,
the service file was generated by the "manage-procs add" command from the systemd-utils provided in the procserv sources.
You might try switching to a system unit, with a user/group specified.
This way the instance can be started a boot, while the procServ process
is started as a non-root user. And a non-root user can telnet in to
start/stop the process being managed.
sudo manage-procs add --user pi --group pi ...
Also, fyi. manage-procs uses a systemd generator to create the service files.
I also tried to enable linger as Andrew suggested, but I'm not sure the shutdown of the IOC was always related to closing the ssh connection to the raspi.
I'll keep an eye on it.
Here is the service file:
pi@scatterchamber:~ $ cat .config/systemd/user/multi-user.target.wants/procserv-epicsioc.service
[Unit]
Description=procServ for epicsioc
After=network.target remote-fs.target
ConditionPathIsDirectory=/home/pi
[Service]
Type=simple
ExecStart=/usr/local/bin/procServ-launcher --user epicsioc
RuntimeDirectory=procserv-epicsioc
StandardOutput=syslog
StandardError=inherit
SyslogIdentifier=procserv-epicsioc
[Install]
WantedBy=multi-user.target
Cheers,
Florian
Am 23.05.2022 um 16:57 schrieb montis:
Hi Florian,
could you be so kind to add the systemd service file you are using for this application? It would be useful.
You can find it under //etc/systemd/sytem/ or //etc/procServ.d/
Thanks in advance!
Maurizio
Il 2022-05-23 10:59 Florian Feldbauer via Tech-talk ha scritto:
Hi Ralph,
I actually feared, that is has nothing to do with procserv or the ioc itself.
Unfortunately I'm not an expert for systemd myself, but I hope someone in this forum has some ideas....
Cheers,
Florian
On 5/23/22 10:54, Ralph Lange via Tech-talk wrote:
Hi Florian,
Doesn't the third line of your log
On Mon, 23 May 2022 at 10:32, Florian Feldbauer via Tech-talk <tech-talk at aps.anl.gov> wrote:
Hey all,
I currently have a problem with procserv.
I'm using the latest commit from github compilied on Raspbian OS bullseye.
I used manage-procs to create a service but the service gets stopped
every now and then.
The actual runtime seems to be quite arbitrary. Sometimes a few secs
sometimes several hours.
The log output does not really contain any helpfull information.
Any idea what could causing procserv to shut down?
CPU and RAM usage are way below 10% when the IOC is running.
Cheers,
Florian
pi@scatterchamber:~ $ systemctl --user status procserv-epicsioc.service
● procserv-epicsioc.service - procServ for epicsioc
Loaded: loaded
(/home/pi/.config/procServ.d/procserv-epicsioc.service; enabled; vendor
preset: enabled)
Active: inactive (dead)
May 23 10:10:17 scatterchamber procserv-epicsioc[58686]: 2022/05/23
10:10:17.505 drvModbusAsyn::doModbusIO port chillerReadReg error calling
writeRead, error=PilotONE-187144:502 TCP timeout>
May 23 10:10:18 scatterchamber procserv-epicsioc[58686]: 2022/05/23
10:10:18.604 drvModbusAsyn::doModbusIO port chillerReadReg writeRead
status back to normal having had 1 errors, nwrite=6/>
i.e., the next one
May 23 10:10:45 scatterchamber systemd[58650]: Stopping procServ for
epicsioc...
May 23 10:10:45 scatterchamber procserv-epicsioc[58686]: @@@ Current
time: Mon May 23 10:10:45 2022
May 23 10:10:45 scatterchamber procserv-epicsioc[58686]: @@@ Child
process is shutting down, a new one will be restarted shortly
May 23 10:10:45 scatterchamber procserv-epicsioc[58686]: @@@ ^R or ^X
restarts the child, ^Q quits the server, ^D closes this connection
May 23 10:10:45 scatterchamber systemd[58650]:
procserv-epicsioc.service: Succeeded.
May 23 10:10:45 scatterchamber systemd[58650]: Stopped procServ for
epicsioc.
May 23 10:10:45 scatterchamber systemd[58650]:
procserv-epicsioc.service: Consumed 1.799s CPU time.
suggest that systemd is deliberately shutting down the IOC?
The following log lines definitely look like procServ was told to shut down the child process.
I'm not a systemd expert enough to know what could cause that (wrong dependencies between services maybe?), but this doesn't really look like something originating within procServ or the child process.
Cheers,
~Ralph
--
Ruhr-Universität Bochum
AG der Experimentalphysik I
Dr. Florian Feldbauer
NB 2/131 / Fach 125
Universitätsstr. 150
D-44801 Bochum
Office: NB 2/134
Phone: (+49)234 / 32-23563
Fax: (+49)234 / 32-14170
https://paluma.ruhr-uni-bochum.de
--
~~ Maurizio Montis - Control System Engineer ~~
office: +39 0498068558
mobile: +39 3408428089
mail: maurizio.montis at lnl.infn.it
skype: maurizio_montis
Istituto Nazionale di Fisica Nucleare - Laboratori Nazionali di Legnaro
V.le dell'Universita', 2
35020 LEGNARO (PD) - ITALY
--
Ruhr-Universität Bochum
AG der Experimentalphysik I
Dr. Florian Feldbauer
NB 2/131 / Fach 125
Universitätsstr. 150
D-44801 Bochum
Office: NB 2/134
Phone: (+49)234 / 32-23563
Fax: (+49)234 / 32-14170
https://paluma.ruhr-uni-bochum.de
- Replies:
- Re: issue with procserv Florian Feldbauer via Tech-talk
- References:
- issue with procserv Florian Feldbauer via Tech-talk
- Re: issue with procserv Ralph Lange via Tech-talk
- Re: issue with procserv Florian Feldbauer via Tech-talk
- Re: issue with procserv montis via Tech-talk
- Re: issue with procserv Florian Feldbauer via Tech-talk
- Navigate by Date:
- Prev:
Re: issue with procserv Han Lee via Tech-talk
- Next:
Re: issue with procserv Florian Feldbauer via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
<2022>
2023
2024
- Navigate by Thread:
- Prev:
Re: issue with procserv Han Lee via Tech-talk
- Next:
Re: issue with procserv Florian Feldbauer via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
<2022>
2023
2024
|