Implement closing wireproxy instance with command

[pufferffish]

Glad to hear this exciting news.
Many WARP users have reported such a need.
I also hope the parameter to close wireproxy. Now I need to use kill -9 $(pgrep -f wireproxy), which seems rude and unprofessional.

Originally posted by @fscarmen in #19 (comment)

[pufferffish]

Related to #16

[pufferffish]

On further consideration, I think this is out of scope for the project. Such features are better left to other programs that manage wireproxy (e.g. systemd / runit or other init systems).

If someone thinks this would be an essential feature, feel free to comment or reopen the issue.

[fscarmen]

On further consideration, I think this is out of scope for the project. Such features are better left to other programs that manage wireproxy (e.g. systemd / runit or other init systems).

If someone thinks this would be an essential feature, feel free to comment or reopen the issue.

Agree. Now my systemd file is

[Unit]
Description=WireProxy for WARP
After=network.target
Documentation=https://github.com/fscarmen/warp
Documentation=https://github.com/octeep/wireproxy

[Service]
ExecStart=/usr/bin/wireproxy /etc/wireguard/proxy.conf
RemainAfterExit=yes
Restart=always

[Install]
WantedBy=multi-user.target

Turn of: systemctl statrt wireproxy
Turn off: systemctl stop wireproxy
Daemon:systemctl enable --now wireproxy
Disable:systemctl disable --now wireproxy

[fscarmen]

On further consideration, I think wireguard-tools have open and close options. wg-quick up and down. So WireProxy can pass parameter to switch on off should be better. Finish himself.

[pufferffish]

On further consideration, I think wireguard-tools have open and close options. wg-quick up and down. So WireProxy can pass parameter to switch on off should be better. Finish himself.

True, but I don't think we can easily implement this feature like wg-quick. wg-quick assumes you have root access and only one instance of wireguard running on your computer. Wireproxy can have multiple different instances running, each belonging to a different user. We can implement this feature by making pidfiles and keeping track of running wireproxy instances in a directory, but then we are reinventing init systems.

For this reason I don't think it is suitable to implement this feature. Multiple wireproxy instances can be achieved by having different systemd services. This responsibility shouldn't be handled by wireproxy.