LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Any framework to support equivalence of systemd.socket (https://www.linuxquestions.org/questions/slackware-14/any-framework-to-support-equivalence-of-systemd-socket-4175643533/)

MQMan 12-03-2018 01:14 AM

Any framework to support equivalence of systemd.socket
 
Does anyone know if there are any frameworks/programs around that will allow the .socket file technique from systemd to be used on Slack.

I'm fairly used to making applications that just use .service files run, as that's usually just the case of creating the right shell script to run the program.

But the whole .socket concept used to then start a .service file is a whole different beast.

Or (maybe) just some hints on the sequence of events in setting up the socket, the listener, and the handoff between the client (which I assume writes to the socket) and the server which is then started as a result.

Cheers.

ponce 12-03-2018 01:57 AM

https://www.freedesktop.org/software...md.socket.html

IMHO the whole thing has sense only when used with systemd, trying to port that logic to the Slackware init scripts will mean, at least, rewriting all of them from scratch, taking away muuuch more time than it's worth and with an end result that won't be even close to the goal (I strongly doubt something like that will work with a shell-based init system)...
always remember the "if it's not broken don't fix it!"™️ golden rule! ;)

MQMan 12-03-2018 03:03 AM

I'd already read up on what the .socket files are. And I'm not trying to re-write any init scripts.

I'm trying to run a (compiled code only) application that uses a single .service file to run the system daemon (as root) and a .socket file to create a file-based socket to listen for commands from the user-land part sent to the daemon.

Cheers.

enorbet 12-03-2018 04:34 AM

Won't Docker do that?

ponce 12-03-2018 05:16 AM

Quote:

Originally Posted by MQMan (Post 5932741)
I'd already read up on what the .socket files are. And I'm not trying to re-write any init scripts.

I'm trying to run a (compiled code only) application that uses a single .service file to run the system daemon (as root) and a .socket file to create a file-based socket to listen for commands from the user-land part sent to the daemon.

*.service files on systemd OSes are handled by the init system: IMHO, if you are trying to implement something similar that handles them in a non-systemd OS you have to do it at that level...

if you need all of this just for an application, running it in a container, like enorbet suggested, could be enough.

another alternative could be to implement what is written on the service file in another shell script written from scratch, but in that case, the shell script doesn't necessarily need to do everything described in the service files, behaving like systemd does (creating sockets, forking, etc., obviously depending on the application): I'll paste below, as an example, the httpd service file and /etc/rc.d/rc.httpd from Slackware
Code:

[Unit]
Description=Apache Web Server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/httpd/httpd.pid
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl graceful-stop
ExecReload=/usr/sbin/apachectl graceful
PrivateTmp=true
LimitNOFILE=infinity

[Install]
WantedBy=multi-user.target

Code:

#!/bin/sh
#
# /etc/rc.d/rc.httpd
#
# Start/stop/restart/graceful[ly restart]/graceful[ly]-stop
# the Apache (httpd) web server.
#
# To make Apache start automatically at boot, make this
# file executable:  chmod 755 /etc/rc.d/rc.httpd
#
# For information on these options, "man apachectl".

case "$1" in
  'start')
    /usr/sbin/apachectl -k start
  ;;
  'stop')
    /usr/sbin/apachectl -k stop
    pkill -f /usr/sbin/httpd
    # Remove both old and new .pid locations:
    rm -f /var/run/httpd.pid /var/run/httpd/httpd.pid
  ;;
  'force-restart')
    # Because sometimes restarting through apachectl just doesn't do the trick...
    /usr/sbin/apachectl -k stop
    pkill -f /usr/sbin/httpd
    # Remove both old and new .pid locations:
    rm -f /var/run/httpd.pid /var/run/httpd/httpd.pid
    /usr/sbin/apachectl -k start
  ;;
  'restart')
    /usr/sbin/apachectl -k restart
  ;;
  'graceful')
    /usr/sbin/apachectl -k graceful
  ;;
  'graceful-stop')
    /usr/sbin/apachectl -k graceful-stop
  ;;
  *)
    echo "Usage: $0 {start|stop|restart|graceful|graceful-stop}"
  ;;
esac


MQMan 12-03-2018 10:39 AM

Quote:

Originally Posted by ponce (Post 5932772)
another alternative could be to implement what is written on the service file in another shell script written from scratch

I'd already indicated I know how to do that.
Quote:

Originally Posted by MQMan (Post 5932720)
I'm fairly used to making applications that just use .service files run, as that's usually just the case of creating the right shell script to run the program.

Quote:

Originally Posted by ponce (Post 5932772)
but in that case, the shell script doesn't necessarily need to do everything described in the service files, behaving like systemd does (creating sockets, forking, etc., obviously depending on the application)

This is the part I'm looking for assistance on, because that's an important part of the application and won't run without it.
Quote:

Originally Posted by enorbet (Post 5932764)
Won't Docker do that?

The way the application works, is that the user-space application, which can be run by any user, needs the daemon to perform (some) actions that need root access on it's behalf, via a file-based socket. Can that daemon, running in Docker, perform those actions for any user-space application.

Cheers.

ponce 12-03-2018 10:42 AM

it depends on what the daemon with root access does.
it's hard to try to understand what you need based on generic behaviours: maybe if you point at the application of which you are speaking of somebody could have a look at its specific behaviour.
if you already have analyzed its specific behaviour, maybe trying to explain it in detail (what you expect in detail from the user space application, what specific actions the daemon performs, etc.) could help also.

also, as this doesn't seem to have much to do with Slackware in particular, I suppose you might have a much better help in the programming section.

Richard Cranium 12-03-2018 11:18 PM

Quote:

Originally Posted by MQMan (Post 5932741)
I'd already read up on what the .socket files are. And I'm not trying to re-write any init scripts.

I'm trying to run a (compiled code only) application that uses a single .service file to run the system daemon (as root) and a .socket file to create a file-based socket to listen for commands from the user-land part sent to the daemon.

Cheers.

Use DBus to talk to your daemon (which is always running). The protocol's there already.


All times are GMT -5. The time now is 01:49 PM.