I have setup a Fossil server with fossil --localauth --localhost -port 8080 --repolist /my/repos in my development machine running macOS High Sierra. When I access the Admin page of a repository I see these warnings:

WARNING: Device "/dev/null" is not available for reading and writing.

WARNING: Device "/dev/urandom" is not available for reading. This means that the pseudo-random number generator used by SQLite will be poorly seeded.

I couldn't find any information about how to fix them. Any Idea?

Using: fossil version 2.7 [9aa9ba8bd2] 2018-09-22 17:40:11 UTC

Do you only see the message when using --localauth and a repo list? What about plain fossil server or fossil ui within your fossil repo?

Does it work with the --nojail option?

Thanks for your replies. I now realise that I should have provided more details. The issue appears only if I run fossil server as root: and in that case, yes, --nojail option solves it.

In fact, I have created a launchd plist in /Library/LaundhDaemons to launch Fossil as startup. It was running Fossil as root, but since that doesn't sound like an award-winning idea, rather than adding --nojail I have now set it to run as a different user.

For the record, the plist looks as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>me.lifepillar.fossil.plist</string>
  <key>KeepAlive</key>
  <true/>
  <key>RunAtLoad</key>
  <true/>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/fossil</string>
    <string>server</string>
    <string>--localauth</string>
    <string>--localhost</string>
    <string>--repolist</string>
    <string>--port</string>
    <string>7055</string>
    <string>/Users/me/Documents/Repositories</string>
  </array>
  <key>UserName</key>
  <string>me</string>
</dict>
</plist>

Adding the UserName key (which causes the job to be run as me) fixed my issue.

Thanks again!

I'm glad it works!

Yes, the --nojail option should probably be used for testing and debugging, only.

I've come across a similar issue with a shell script, and the solution was to make /dev/null explicitly available to the "chroot jail".

But neither do I remember how this was done in the script, nor do I know how Fossil achieves this, and why it failed in your case.

Thanks for the information. Ah yes, I think the shell script also worked with mknod, but deleted everything when done, so I must have assumed this is the usual way.

I always forget about the old Mailing List Archives, where this topic was also discussed:

• [fossil-users] Problem with /dev/random and /dev/null in latest versions?
• [fossil-users] /dev/null and /dev/urandom not available ?

I always forget about the old Mailing List Archives

It didn't occur to me to search there either (since Gmane has gone offline, I haven't found a convenient way to follow the many mailing lists I used to follow…).

Perhaps it would be possible to migrate the old posts into this forum?

Gmane has gone offline

So much for the argument that 3rd parties are reliable archivists for a project's discussion forum.

Not that we needed that particular example, as we had multiple prior examples. Whither Deja News, for example? Don't tell me Google Groups: there's tons of past posts on Usenet that you can no longer find through it.

That's the beauty of Fossil Forums: as long as one clone of the repo exists, the archive is complete and ready to be stood back up on an alternate substrate.

Call to action: clone this forum now, and script a regular sync.

Perhaps it would be possible to migrate the old posts into this forum?

Already discussed.

Someone's just got to get around to working through the details.