Safely Test and Reseed a System with pollinate

You will finish with a verified way to test pollinate's connection to an entropy server, understand what the client writes, and request a later reseed without weakening TLS verification. The examples match pollinate 4.33-3.1ubuntu1.3 installed on Ubuntu 24.04.5 LTS.

Allow about fifteen minutes. You need the pollinate package, a working network connection, and a shell. A communication test is unprivileged. The normal seeding path writes to /dev/urandom and uses /var/cache/pollinate, so it is normally run by the package's pollinate service account or through its systemd service, not casually as root.

1. Confirm the installed client

Check which executable is being used and record the package version. These are read-only commands and do not need elevated privileges:

$ command -v pollinate
/usr/bin/pollinate
$ dpkg-query -W -f='${Package} ${Version}\n' pollinate
pollinate 4.33-3.1ubuntu1.3

pollinate is a shell client. Its normal job is to fetch data from one or more remote servers, hash the response with SHA-512, and feed the result to a device. The installed manual documents options such as --server, --pool, --device, --testing and --strict.

Checkpoint: print the client user-agent without contacting an entropy server:

$ pollinate --print-user-agent
curl/8.5.0-2ubuntu10.15 pollinate/4.33-3.1ubuntu1.3 ...

The trailing fields identify local package, operating-system and machine details. They vary by host, so do not compare the whole line as a fixed string.

2. Test communication without seeding

Use --testing for a smoke test. It communicates with the configured server but does not seed the pseudo-random number generator. Testing mode also forces the output device to standard output, which makes it suitable for a normal user account:

$ pollinate --testing
<binary or diagnostic output may vary>

Do not treat the displayed bytes as a stable sample to parse. The useful result is whether the command completes and whether it reports a network or protocol error. Since the normal configuration uses binary output, terminal output can look unreadable. Direct it to a temporary file if you need to inspect the exit status without filling your terminal:

$ tmpfile=$(mktemp)
$ if pollinate --testing >"$tmpfile"; then
>     printf 'communication test passed, %s bytes received\n' "$(wc -c <"$tmpfile")"
> else
>     status=$?
>     printf 'communication test failed, exit status %s\n' "$status" >&2
> fi
$ rm -f -- "$tmpfile"
communication test passed, 64 bytes received

The byte count and exact logs can differ. The temporary file is safe to remove after the check because it is only the test output. If the command warns about a network failure, rerun with --strict when a script must fail rather than accept pollinate's default warning behaviour.

3. Understand the normal destination

Without --testing, the installed defaults use binary mode and target /dev/urandom. The client also records a marker under /var/cache/pollinate/seeded. A successful first run is therefore treated as enough for the machine unless you explicitly request a reseed.

This is a state-changing operation. Do not redirect a normal run to a regular file while trying to "see what it writes": changing --device changes where the hash is sent, and a mistaken path can overwrite data. Do not use --insecure to get around a certificate problem. The manual strongly discourages it because it removes certificate verification; fix the trust store, proxy or server configuration instead.

For an installed system service, inspect the unit before changing anything:

$ systemctl cat pollinate.service
[Service]
User=pollinate
ExecStart=/usr/bin/pollinate
Type=oneshot

On this installation the unit runs as pollinate, waits for the network, and is skipped when the cache marker already exists. Reading the unit is unprivileged. Starting or restarting a service requires elevated privileges and can make a network request, so schedule that work deliberately:

$ sudo systemctl start pollinate.service
$ systemctl show -p Result -p ExecMainStatus pollinate.service
Result=success
ExecMainStatus=0

The exact systemctl show output is host-specific. A successful unit result means the command returned successfully; it does not prove that every later consumer has a particular entropy level.

4. Request a deliberate reseed

After the first successful run, pollinate normally exits after reporting that the system was already seeded. Use --reseed when you have a specific operational reason to run it again:

$ sudo -u pollinate pollinate --reseed
$ systemctl status --no-pager pollinate.service
pollinate.service - Pollinate to seed the pseudo random number generator
   Active: inactive (dead)

The status display varies by systemd version. The important checks are that the command did not report a network or certificate error and that it returned status zero. If your installation's cache directory permissions do not allow this direct invocation, use the service instead:

$ sudo systemctl restart pollinate.service
$ systemctl show -p Result -p ExecMainStatus pollinate.service
Result=success
ExecMainStatus=0

There is no useful undo operation for a reseed. It changes the kernel's random-device state and the cache marker, rather than creating a document that can be restored. If a service restart was accidental, stop making further changes and review its journal:

$ sudo journalctl -u pollinate.service -n 50 --no-pager

5. Diagnose server and option mistakes

Use --server to select one server for a test. Supplying it causes the configured pool to be ignored. A URL can include its scheme; pollinate adds https:// when it is absent:

$ pollinate --testing --server https://entropy.ubuntu.com/
<test output>

Use repeated --pool options when you intentionally want several servers. Keep the server list short and trusted. The challenge and response is enabled by default; --no-challenge is a compatibility mode for servers that cannot perform that exchange, not a general troubleshooting switch.

For scripts, add --strict so a network error exits non-zero. Without it, the documented default is to warn, which can let a wrapper continue after a failed exchange. Add --wait SECONDS to bound each server request when the default is not suitable. Check the value before running it, because an unnecessarily long wait can hold up boot or service maintenance.

When debugging, leave TLS verification enabled and avoid putting sensitive curl options in shell history. The --curl-opts option passes text through to curl, so treat it as an advanced interface and keep its value under your control.