JitterEntropy Fails to Start via SystemD - ESXI 6.0 / Ubuntu 18.04 / 5.10.71-xanmod1

[weaselBuddha]

PID: 14726 (jitterentropy-r)
UID: 0 (root)
GID: 0 (root)
Signal: 31 (SYS)
Timestamp: Tue 2021-10-12 03:31:54 CEST (31min ago)
Command Line: /usr/local/sbin/jitterentropy-rngd
Executable: /usr/local/sbin/jitterentropy-rngd
Control Group: /system.slice/jitterentropy.service
Unit: jitterentropy.service
Slice: system.slice
Boot ID: 1ca270628e4940c7a35ebd0f29ac0c38
Machine ID: 7ae74b38bb314eb08357f142b6314be3
Hostname: rascal
Storage: /var/lib/systemd/coredump/core.jitterentropy-r.0.1ca270628e4940c7a35ebd0f29ac0c38.14726.1634002314000000.lz4
Message: Process 14726 (jitterentropy-r) of user 0 dumped core.

            Stack trace of thread 14726:
            #0  0x00007f5c968420a9 n/a (/lib/x86_64-linux-gnu/ld-2.27.so)
            #1  0x00007f5c96840df1 n/a (/lib/x86_64-linux-gnu/ld-2.27.so)
            #2  0x00007f5c96828128 n/a (/lib/x86_64-linux-gnu/ld-2.27.so)
            #3  0x00007f5c96827098 n/a (/lib/x86_64-linux-gnu/ld-2.27.so)

Status Entry:

● jitterentropy.service - Jitterentropy Gatherer Daemon
Loaded: loaded (/lib/systemd/system/jitterentropy.service; enabled; vendor pr
Active: failed (Result: signal) since Mon 2021-10-11 05:42:13 CEST; 12s ago
Process: 7972 ExecStart=/usr/local/sbin/jitterentropy-rngd (code=killed, signa
Main PID: 7972 (code=killed, signal=SYS)

Bad system call....

--

To fix had to comment out, from /lib/systemd/system/jitterentropy.service the lines:

#SystemCallFilter=@System-service
#SystemCallFilter=~@chown @clock @cpu-emulation @debug @ipc @module @mount @obsolete @PRIVILEGED @raw-io @reboot @resources @swap memfd_create mincore mlock mlockall personality

It will now start, no problem.

God I hate systemD

[smuellerDD]

Am Dienstag, 12. Oktober 2021, 04:12:20 CEST schrieb wBuddha: Hi wBuddha,

PID: 14726 (jitterentropy-r) UID: 0 (root) GID: 0 (root) Signal: 31 (SYS) Timestamp: Tue 2021-10-12 03:31:54 CEST (31min ago) Command Line: /usr/local/sbin/jitterentropy-rngd Executable: /usr/local/sbin/jitterentropy-rngd Control Group: /system.slice/jitterentropy.service Unit: jitterentropy.service Slice: system.slice Boot ID: 1ca270628e4940c7a35ebd0f29ac0c38 Machine ID: 7ae74b38bb314eb08357f142b6314be3 Hostname: rascal Storage: /var/lib/systemd/coredump/core.jitterentropy-r.0.1ca270628e4940c7a35ebd0f29 ac0c38.14726.1634002314000000.lz4

Message: Process 14726 (jitterentropy-r)

of user 0 dumped core. Stack trace of thread 14726: #0 0x00007f5c968420a9 n/a (/lib/x86_64-linux-gnu/ld-2.27.so)

#1 0x00007f5c96840df1 n/a

(/lib/x86_64-linux-gnu/ld-2.27.so) #2 0x00007f5c96828128 n/a (/lib/x86_64-linux-gnu/ld-2.27.so) #3 0x00007f5c96827098 n/a (/lib/x86_64-linux-gnu/ld-2.27.so) Status Entry: ● jitterentropy.service - Jitterentropy Gatherer Daemon Loaded: loaded (/lib/systemd/system/jitterentropy.service; enabled; vendor pr

Active: failed (Result: signal) since Mon 2021-10-11 05:42:13

CEST; 12s ago Process: 7972 ExecStart=/usr/local/sbin/jitterentropy-rngd (code=killed, signa Main PID: 7972 (code=killed, signal=SYS) Bad system call....

That is a very interesting report. A bad system call means the code uses a syscall that is not present on your system. Can you invoke the daemon manually with strace to see which syscall it is that seems to offend your system? Thanks Stephan

-- To fix had to comment out, from /lib/systemd/system/jitterentropy.service the lines: ***@***.*** ***@***.*** @clock @cpu-emulation @debug @ipc @module @mount @obsolete @PRIVILEGED @raw-io @reboot @resources @swap memfd_create mincore mlock mlockall personality It will now start, no problem. God I hate systemD -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #24

Ciao Stephan

[weaselBuddha]

Isn't that what the systemd directives do? Limit what system calls that can be made (looks like the directives are being treated as e-mail addresses)

SystemCallFilter = @ system-service
SystemCallFilter=~ (list of calls)

If you comment out those two lines from the systemd service file, it starts fine

I had to systematically go thru to find them, because indeed, it started from the command line. Your systemd service file in my case (ESXi/Xanmod/18.04) was the culprit that was causing the failure.

ESXi creates part of this I suspect, there is no virtualized HWRNG device - hence the need for your package (entropy starvation is common)

It is working great for me now, just wanted to make an entry in case others have the same problem.

[smuellerDD]

Am Mittwoch, 13. Oktober 2021, 00:00:41 CEST schrieb wBuddha: Hi wBuddha,

Is that what the systemd directives do? Limit what system calls can be made (looks like the directives are being treated as e-mail addresses) SystemCallFilter = @ system-service SystemCallFilter=~ (list of calls)

Sorry for the delay. Please perform the following invocation strace -ff -o output .../jitterentropy-rngd Send me the output.* files. Ciao Stephan

[weaselBuddha]

Hope this is enough:

https://pastebin.com/kvGRk4Q7

[smuellerDD]

Am Donnerstag, 4. November 2021, 20:02:39 CET schrieb wBuddha: Hi wBuddha,

Hope this is enough: https://pastebin.com/kvGRk4Q7

Yes, that is exactly what I am looking for - but I wonder whether the trace is complete. It cuts off in the middle of the select call. I actually need the last lines shortly before the crash. Ciao Stephan

[weaselBuddha]

Stephan,

Jeez I hate systemd.

Failure only happens within the context of the systemd startup, so had to rig the strace there (and remember to do a systemctl reset-failed)

STrace Output: https://github.com/weaselBuddha/JitterFail

[smuellerDD]

Am Sonntag, 7. November 2021, 00:21:50 CET schrieb wBuddha: Hi wBuddha,

Stephan, Jeez I hate systemd. Failure only happens within the context of the systemd startup, so had to rig the strace there (and remember to do a systemctl reset-failed) STrace Output: https://github.com/weaselBuddha/JitterFail

You seem to use quite an old version: stat("/proc/sys/kernel/random/lrng_type", 0x7fff97270090) = -1 ENOENT (No such file or directory) This file was accessed before rngd version 1.2.0 That said, neither log shows any crash, segfault or other termination. Ciao Stephan

[weaselBuddha]

Sorry about the version, I working across multiple servers. No difference with a new made pull.

I'm convinced that is a systemd affectation, it is killing jitter based on the system call limitations imposed by the SystemCallFilters defined in your systemd startup. Systemd is anything other than transparent.

I don't think there is a code problem in Jitter.

It runs fine from the command line.

It fails if called from the default systemd service file.

It runs fine if I comment out the SystemCallFilters directives in the systemd file.

The straces look identical, failed vs success, it just doesn't start up with the directives in place.

I'm glad to spin up a server for you so you can look hands-on if that helps - write me.

To us, with the directives disabled, it works great, thank you for the tool - vmware esxi doesn't give us a hardware or virtualized random device.

[smuellerDD]

Am Montag, 8. November 2021, 18:53:41 CET schrieb wBuddha: Hi wBuddha,

Sorry about the version, I working across multiple servers. No difference with a new made pull. I'm convinced that is a systemd affectation, it is killing jitter based on the system call limitations imposed by the SystemCallFilters defined in your systemd startup. Systemd is anything other than transparent.

With my latest code: # make install strip --strip-unneeded jitterentropy-rngd install -D -m 0755 jitterentropy-rngd /usr/local/sbin/jitterentropy-rngd install -D -m 0644 jitterentropy-rngd.1 /usr/local/share/man/man1/ jitterentropy-rngd.1 gzip -9 /usr/local/share/man/man1/jitterentropy-rngd.1 sed ***@***.***@|/usr/local/sbin|" jitterentropy.service.in > jitterentropy.service install -D -m 0644 jitterentropy.service /usr/lib/systemd/system/ jitterentropy.service # systemctl start jitterentropy # systemctl status jitterentropy ● jitterentropy.service - Jitterentropy Gatherer Daemon Loaded: loaded (/etc/systemd/system/jitterentropy.service; disabled; vendo> Active: active (running) since Mon 2021-11-08 19:01:03 CET; 6s ago Main PID: 374628 (jitterentropy-r) Tasks: 1 (limit: 18759) Memory: 504.0K CPU: 159ms CGroup: /system.slice/jitterentropy.service └─374628 /usr/local/sbin/jitterentropy-rngd # ps -efa | grep jitter root 374628 1 0 19:01 ? 00:00:00 /usr/local/sbin/ jitterentropy-rngd

I don't think there is a code problem in Jitter. It runs fine from the command line. It fails if called from the default systemd service file. It runs fine if I comment out the SystemCallFilters directives in the systemd file. The straces look identical, failed vs success, it just doesn't start up with the directives in place. I'm glad to spin up a server for you so you can look hands-on if that helps - write me.

I would be happy to have a look.

To us, with the directives disabled, it works great, thank you for the tool - vmware esxi doesn't give us a hardware or virtualized random device.

:-) Ciao Stephan

[weaselBuddha]

Sing the bonehead song, closing the issue. Failure of basic hygiene I guess.

Rerunning on a fresh server, new version of jitter, ran fine. The problem with the previous version (systemd sucks), will remain a mystery.

Fixing our server template to latest version.