Skip to main content ↑ ↓
Topic: L2TP/IPSEC client on artix runit (Read 1964 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

L2TP/IPSEC client on artix runit

I would like to install an L2TP client, and I followed instructions from Arch wiki. The instructions are to install xl2tpd and openswan service, and then must start services. There are no runit versions of those packages. Does anyone have a work around? I  don't currently have the skills to convert a systemd package into a runit package.

Re: L2TP/IPSEC client on artix runit

Reply #1 –
Hello. xl2tpd has a runit service but for now we can't add openswan since it's original systemd servicec file is a forking service (runit does not allow it).
I'll look for a solution.
now only the dinit guy in artix

Re: L2TP/IPSEC client on artix runit

Reply #2 –
Quote from: konimex – on
Hello. xl2tpd has a runit service but for now we can't add openswan since it's original systemd servicec file is a forking service (runit does not allow it).
I'll look for a solution.
IIRC you can run a forking service at the start of the script then exec an infinite sleep for a oneshot effect.

Re: L2TP/IPSEC client on artix runit

Reply #3 –
Quote from: ####### – on
IIRC you can run a forking service at the start of the script then exec an infinite sleep for a oneshot effect.

Then there's no point in making a runit service if the process itself is not supervised. (I'd give a leeway for true oneshot services but forking is a no-no).

Besides, it's a bad design. You really don't need to "daemonize" your daemons because that's the job of service manager.


@Bahuvrihi, There's a fork of openswan (libreswan) that has a working easy-to-convert-to-daemontools-style systemd service, I'll try to convert this one instead to see if this works with openswan too.
now only the dinit guy in artix

Re: L2TP/IPSEC client on artix runit

Reply #4 –
https://linux.die.net/man/1/daemonize

"Upon startup, a typical daemon program will:

Close all open file descriptors (especially standard input, standard
    output and standard error)
Change its working directory to the root filesystem, to ensure that
    it doesn't tie up another filesystem and prevent it from being unmounted
Reset its
    umask value
Run in the background (i.e.,
    fork)
Disassociate from its process group (usually a shell), to insulate
    itself from signals (such as HUP) sent to the process group
Ignore all terminal I/O signals
Disassociate from the control terminal (and take steps not to reacquire one)
Handle any
    SIGCLD signals"

sysv as used by most Linux os's (and still some now) until systemd was introduced required daemons to do this. It also recommended that a PID file was written although it could manage without by searching the PS tree itself, but that relied on the name of the process which could break in some circumstances. And it started everything as a one shot unless you installed a separate service monitor, there was no monitoring at all yet it worked well enough. So that link you quote is just plain wrong.  ;D
There is even a systemd man page: daemon — Writing and packaging system daemons
that will tell you about this too.
The other benefit is if you ever want to run it from a terminal it just automatically goes away and you don't always want it on stderr so it doesn't start unexpectedly printing messages either on the terminal or on the console at boot. But it's better if daemons have an option to run in the foreground, that is usually easily achieved. Older ones may not have this because hardly anyone needed it in the past. Perhaps there is some wrapper that lets Runit handle forking daemons, IDK!

Re: L2TP/IPSEC client on artix runit

Reply #5 –
Quote from: ####### – on
There is even a systemd man page: daemon — Writing and packaging system daemons
that will tell you about this too.
Yes, but from the same systemd daemon page recommends what they call "new-style daemons" aka. what daemontools and it's family have been approaching for years (specifically numbers 1, 2, 3, and 10 since 4 through 9 is systemd-specific) and only use the forking apporach "should only be implemented if compatibility with SysV is essential."

Quote from: ####### – on
The other benefit is if you ever want to run it from a terminal it just automatically goes away and you don't always want it on stderr so it doesn't start unexpectedly printing messages either on the terminal or on the console at boot.
Yes, but we're talking about services that run automatically on boot so we don't have to run it manually on terminal. Besides, all daemontools-family tools will redirect any and all stdout/stderr outputs to a log service (usually svlogd/syslog). Of course, backgrounding a process (not service) has its own benefits.

Quote from: ####### – on
Perhaps there is some wrapper that lets Runit handle forking daemons, IDK!
daemontools has a tool for forcing a program to use foreground mode, fghack, but the creator recommends to "fix the daemon" instead of using fghack since it's a bad design.

This is getting off-topic so this is my last reply on this matter. I'm working on making libreswan run on my own system to test it before adding the runit service.
now only the dinit guy in artix

Re: L2TP/IPSEC client on artix runit

Reply #6 –
@Bahuvrihi, what's the output of pacman -Ql openswan?
now only the dinit guy in artix

Re: L2TP/IPSEC client on artix runit

Reply #8 –
@konimex
Sorry for late response (I don't get alerted, just check back from time to time)
Attached is the output of pacman -Ql openswan