I have created a systemd service like way any interruption triggered to running process then it has to restart itself. but service shows its status as running (Used systemctl status x.service) even after process is exited (which is mentioned in exec_start).
Below is my service script
{
[Unit]
Description=xserverd
After=syslog.target rsyslog-x.service systemd-modules-load.service
Requires=rsyslog-x.service systemd-modules-load.service
[Service]
Type=forking
ExecStart=/opt/bin/xserver
Restart=always
RestartSec=2s
RemainAfterExit=no
RestartPreventExitStatus=SIGINT
KillMode=process
TimeoutSec=300s
[Install]
WantedBy=multi-user.target
}
/opt/bin/xserver is a C executable which 777 permission. Added signal handler for SIGINT and SIGSEGV. SIGINT is to say proper exit from user. SIGSEGV to log backtrace to our custom log file. Whenever process receives these signals it will exit with
{
exit(EXIT_FAILURE)
}
For Type=forking, systemd assume the child or child of child of the start command is the daemon process.
Change it to simple if your daemon does not go this way.
Related
My situation of my apache2 service now :
main process was down, only child processes were running
How can I get value of main process when it dead or active ?
I have configured xinetd to launch NSCA when a connection on port 5667 is made.
I can start xinetd by command line as root and things work correctly:
/usr/sbin/xinetd -stayalive -pidfile /var/run/xinetd.pid
I can send a test NSCA message to myself, and /var/log/messages shows NSCA daemons getting spun up, writing to nagios.cmd pipe, etc.
But, when run by systemctl start xinetd, my test messages fail with "Server closed connection before init packet was received"
The xinetd service appears the same in ps -ef | grep xinetd regardless of which way it's run.
I don't think its a user or permissions problem, as it should be running as root.
Not having much luck getting NSCA or XINETD to log any relevant info on why its attempting to spin up the NSCA daemon but immediately exiting...
See below for my nsca file for xinetd
service nsca
{
flags = REUSE
socket_type = stream
wait = no
user = root
group = root
server = /usr/sbin/nsca
server_args = -c /usr/local/nagios/etc/nsca.cfg --inetd
log_on_failure += USERID
disable = no
only_from = <list of allowed hosts>
instances = UNLIMITED
per_source = UNLIMITED
cps = 5000 0
}
Solution:
I learned that when systemd launches a process, its in a clean slate environment. So, anything run by xinetd that requires environment variables needs those env vars passed in xinetd's environment file (a field in /lib/systemd/system/xinetd.service called "EnvironmentFile"). For me that lives at: /etc/sysconfig/xinetd
To find which vars I need, in the bash window in which running xinetd manually was WORKING, 'env' spit out all the vars.
Copied them all into /etc/sysconfig/xinetd, then 'systemctl restart xinetd' and all worked.
Then just through process of elimination determined the envvar I was missing was:
LD_LIBRARY_PATH=:/usr/local/libmcrypt/lib
I want to build a system with applications on another partition, an app-filessystem. All binaries, configs and service files which belong to the application should be in the app-fs.
I'm using the following versions: kernel 4.9.x, systemd v234.
The app-partition is mounted at /opt, this includes following files:
/opt/usr/bin/app-binary
/opt/etc/systemd/system/multiuser.target/link_2_app.service
/opt/lib/systemd/system/app.service
Here is the service file:
[Unit]
Description=The application description.
After=syslog.target basic.target
[Service]
ExecStart=/opt/usr/bin/app-binary
Type=simple
[Install]
WantedBy=multi-user.target
To synchronize the files with rootfilesystem I created 2 overlays, this could be the /etc/fstab entries (sorry for format, one line didn't work):
/dev/app-partition /opt auto defaults,x-systemd.mount 0 2
overlay /etc overlay defaults,x-systemd.mount, x-systemd.after=opt.mount,lowerdir=/etc,upperdir=/opt/etc,workdir=/work/etc 0 2
overlay /lib/systemd/system overlay defaults,x-systemd.mount,x-systemd.after=opt.mount,lowerdir=/lib/systemd/system,upperdir=/opt/lib/systemd/system,workdir=/work/lib 0 2
This is handled before local-fs.target is reached.
Result
I can start the app successfully but manually with systemctl start app.service. The status with "systemctl status app.service" says it is enabled. But the app is not starting at boot time. Systemd does not give a message about trying to start the app.
Questions
Is there a way to debug this behaviour? When does systemd check the service files? Is there a way to trigger it again? Are there other ways to handle this use case with systemd?
systemd is checking the unit files once at start, an init script which is creating the overlayFS before systemd startup can handle this use case.
Another idea (but not tested) would be: systemctl daemon-reload
systemctl daemon-reload
I test this not work.
In my situation . I use systemd-networkd,and I overlay
For disabling autostart of services seems using
ConditionPathIsSymbolicLink=#OVERLAY_UPPER_LAYER#/etc/systemd/system/../XX.service
as additional condition in service drop-in works
I have one agent service (org.bluez.map_agent)
[D-BUS Service]
Name=org.bluez.map_agent
Exec=echo "Hello"
SystemdService=bluetooth-map-agent.service
Content of bluetooth-map-agent.service
[Unit]
Description=launch MAP agent.
[Service]
User=app
ExecStart=/usr/bin/map-agent
ExecStop=/usr/bin/killall map-agent
KillMode=process
[Install]
WantedBy=multi-user.target
But when dbus call happens my map-agent is not getting launched, what could be the reason?
Make your service to launch by systemd itself when the required bus is created by dbus. This can be achieved using below service file:
[Unit]
Description=launch MAP agent.
[Service]
Type=dbus
User=app
BusName=org.bluez.map_agent
ExecStart=/usr/bin/map-agent
ExecStop=/usr/bin/killall map-agent
KillMode=process
[Install]
WantedBy=multi-user.target
And enable your service file using systemctl enable xyz.service
Systemd will wait for bus-name to acquire on dbus, only then service will be activated.
As part of the deployment process of a Glide project (http://glide-gae.appspot.com/docs/intro step 3 of 2nd section) you need to authenticate using oauth2. My browser popped up with the token as expected but the process didn’t wait for me to copy the code in, it just carried on with the following error...
22:30:12.713 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] Daemon is busy, sleeping until state changes.
22:30:12.733 [INFO] [org.gradle.launcher.daemon.server.exec.LogToClient] About to start relaying all logs to the client via the connection.
22:30:12.734 [INFO] [org.gradle.launcher.daemon.server.exec.LogToClient] The client will now receive all logging from the daemon (pid: 12557). The daemon log file: /.gradle/daemon/1.8/daemon-12557.out.log
22:30:12.739 [DEBUG] [org.gradle.launcher.daemon.server.SynchronizedDispatchConnection] thread 14: received class org.gradle.launcher.daemon.protocol.CloseInput
22:30:12.740 [DEBUG] [org.gradle.launcher.daemon.server.DefaultDaemonConnection] Received IO message from client: CloseInput[id=069864b2-2948-4a9d-abea-0705274136a1.2]
22:30:12.741 [INFO] [org.gradle.launcher.daemon.server.exec.ForwardClientInput] Closing daemon's stdin at end of input.
22:30:12.742 [INFO] [org.gradle.launcher.daemon.server.exec.ForwardClientInput] The daemon will no longer process any standard input.
22:30:12.747 [INFO] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] Executing build with daemon context: DefaultDaemonContext[uid=3901cff0-8d50-41b6-9459-e31f7b78f1e3,javaHome=/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home,daemonRegistryDir=.gradle/daemon,pid=12557,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-Xmx512m,-Dfile.encoding=UTF-8]
Please enter code: Encountered a problem: No line found
Please see the logs [/var/folders/c8/vx2jf50j68x1z3_pysy6kxjm0000gp/T/appcfg2389447403250678065.log] for further information.
Daemon vm is shutting down... The daemon has exited normally or was terminated in response to a user interrupt.
----- End of the daemon log -----
org.gradle.tooling.GradleConnectionException: Could not execute build using Gradle distribution 'http://services.gradle.org/distributions/gradle-1.8-bin.zip'.
What can I do to be able to deploy my application? How can I force the process to wait for me to enter the code?
If that's (glide deploy) not working for you, the easiest option is to export the app as a standard gradle project and then execute the gaeUpdate task.
glide -a somedir/yourapp -o where/you/want/to/export/app export
Note that the export is command at the end, -o tell the location where it should be exported.
Then from the exported project run: gradle gaeUpdate
A work around is to manually set your credentials in the GAE build.gradle file.
Update the following file:
/glide/install/generated/app-name/build.gradle
appcfg {
email = ‘email-address'
password = ‘password'
app {
id = ‘app-id'
}
}
This means that the values from the __glide.groovy file are ignored, but at least you can get the application deployed