N ICMP echo request service

icmpnetworkingpingservices

Often, in applications that I develop, I like to include a network status indicator for various devices on the network. The easiest way to monitor these devices is by pinging them. But ICMP echoes are often difficult to integrate into an application due to security requirements with raw sockets, or performance issues with shelling out to ping. Also, for situations where this isn't a problem, I'm kind of over writing slightly different variations of the same ping code for various situations.

Most of the devices that I monitor are embedded devices with minimal network capabilities (but always include ICMP echo), so I do have to stick with this protocol, things like Echo Protocol (pointed out by Mark in comments below, thanks!) usually aren't available to me.

Is there a service that already exists that can provide low-overhead ICMP ping services to a non-root application?

I am considering writing a service that runs as root and allows other non-root applications to connect to it, add devices to monitor, and then query ping times and network status from it, but I don't want to reinvent a wheel and I'm wondering if something like this exists already.

Best Answer

The answer to your question is probably "No, there is not."

The reason for this is that ICMP is a low level protocol, and in order to produce ICMP traffic, an application needs privileged access to your network interface. You can see evidence this on most systems by the fact that the binaries that generate ICMP are set-uid root. Note the sticky bit:

$ ls -l /sbin/ping /usr/sbin/traceroute
-r-sr-xr-x  1 root  wheel  28088 Aug 12 12:19 /sbin/ping
-r-sr-xr-x  1 root  wheel  28608 Aug 12 12:20 /usr/sbin/traceroute

(This is on FreeBSD. Your results on other operating systems may be different.)

For an application to generate raw network traffic, it needs to run as root. Since /sbin/ping already runs as root, your best bet is likely to use it to generate your pings.

If you're doing this for a large number of hosts, you might want to look at fping. Another option would be tcping, which can generate TCP packets that provide similar results to an ICMP ping. The requirement would be an open port on the target system to receive the packet. You might be able to use this or replicate its approach based on the source. Both of these may already be available as a package for your operating system.

For a larger scale monitoring solution, Nagios and Zabbix are popular free options, but there are many others.

Edit `/etc/sysctl.conf`

Add the following line to your /etc/sysctl.conf:

net.ipv4.icmp_echo_ignore_all=1

Then:

sysctl -p

Using iptables:

iptables -I INPUT -p icmp --icmp-type echo-request -j DROP

With cron

Run crontab -e as root, then add the following line:

@reboot echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

Start and enable the service:

systemctl start cron.service
systemctl enable cron.service

Fix systemd Services Failing with User= in Service File

The problem you hit is that System V init scripts expect to run as root, that's part of the "specification" on how they work and they'll often have steps that need root to complete.

In your case, it was about running su <userid> -c ... to actually start running as the non-root user, but that part actually fails if you're already running under that user. System V init scripts will often use tools such as su or runas or similar to switch to a non-root user, but these tools are often not perfectly suited for that purpose (su is originally meant to run from an interactive shell and will integrate with PAM which doesn't make much sense here.)

Even worse, some System V init scripts will not deal with changing user and will end up unnecessarily running a daemon as root, since that's what feels more "natural" in a System V init script. This is, in my opinion, one of the worst issues of System V init scripts, they make it easy to do the wrong thing here, and hard to do the right one.

If you want to keep compatibility with a System V init script, you could just run them as root from systemd, since that's the "protocol" when invoking such scripts. In fact, if you wish to keep compatibility, you don't even need to ship a systemd unit, since systemd will be able to generate one by itself through systemd-sysv-generator. The generated unit will look a lot like the one you presented, except that it will be run by root instead.

If you do want to ship a systemd service unit (which I'd recommend that you do), then you should seriously consider shipping a unit that uses Type=simple, rather than forking.

The only pre-requisite for that is that you're able to start the daemon in foreground, which many daemons are able to do by passing an extra command-line flag or through some configuration. (It actually takes considerably less effort to do so, so if your daemon currently doesn't support that and you have control of the sources, consider adding or requesting that feature.)

At that point, all you need is to call your daemon in foreground from an ExecStart= directive. You don't need an ExecStop=, as long as your daemon properly terminates upon receiving a signal to kill it.

You don't need a pidfile anymore! Since systemd is launching the daemon process in foreground, it knows what the main PID of the daemon process is. This is huge, because pidfiles are often/usually implemented incorrectly (they're supposed to be created only once the daemon is ready to serve), so getting rid of that requirement is quite a big deal.

If you need to export specific environment variables before starting the main process, you can use systemd's Environment= or perhaps EnvironmentFile= to set those variables. (This will work fine, as long as the variables are set to fixed values rather than dynamically generated values.) If you need to execute steps before the daemon starts, you can use ExecStartPre=.

If you need more flexibility (for example, conditionally setting variables or running commands, or setting variables to dynamic values, etc.) then you should wrap the startup in a shell script (or Python, Perl, etc.) and call that script in ExecStart=. The script will set and export any variables needed, run any commands that need to be run, before executing the main daemon.

The important part when using a shell script to start a daemon is to use the exec command, in order to replace the shell with the daemon program. That means the shell will no longer be around, and the daemon will be running under the same PID that was in use by the shell, so systemd will still reliably know the main PID of the daemon. Of course, the daemon exec'd by the shell script should still run in foreground.

Using a Type=simple service allows you to configure User= in the systemd unit itself. Furthermore, you typically can apply more security measures through systemd configuration, that might have tripped a System V init script and prevented their usage. Also, using simple rather than forking makes this setup much more reliable, it's also more efficient on the system.

You can easily ship both a systemd service unit with Type=simple and a System V init script on your package. As long as they have the same name, systemd will prefer the native service unit (so the legacy code of systemd-sysv-generator will not trigger for the init script in that case.) That way you keep compatibility with non-Linux and other non-systemd setups, while at the same time you're able to make the most out of modern Linux systems with systemd.

Best Answer

Related Solutions

Linux – How to Disable Ping Response (ICMP Echo) Permanently

Edit /etc/sysctl.conf

Using iptables:

With cron

Fix systemd Services Failing with User= in Service File

Related Question

Edit `/etc/sysctl.conf`