While you can do it in /etc/fstab, you can also choose to use tmpfs for /tmp in /etc/default/tmpfs, where you can set RAMTMP=yes.

I think that the safest assumption about /tmp is that you cannot guarantee that anything in /tmp will survive a reboot, neither can you guarantee that it won't survive.

Geoff

The comment in /etc/rcS.d/S08checkroot-bootclean.sh seems to suggest that it is only the mount point that is cleaned out, before anything is mounted over the top of it.

Geoff

Is /tmp guaranteed to be empty at Boot?

grep tmp /etc/rcS.d/S06checkroot.sh

returns nothing!

As it is fairly common to mount /tmp as a tmpfs, this will tend to leave it empty on a reboot.

Geoff

The use of CR/LF predates Microsoft and was used by DEC (Digital Equipment Corp).

No, the order that worked was CR/LF, when using a Teletype ASR 33 printer for your output. Having got your print head to the right hand side, you gave it the CR and the print head mechanism set off at high speed for the left hand side of the printer. While it was travelling across you put in the line feed, which is much quicker to execute. By the time you gave it the first character of the next line the print head was in place and all was well. If you gave them in the order LF/CR then the first character of the next line was printed while the print head was still whizzing back and ended up being printed somewhere in the middle of the next line but smudged. I know, I have tried it! We used ASR33s for the output from our isotope counters, using the paper tape punch for our data transfer to our ICL 1903A.

https://en.wikipedia.org/wiki/Teletype_Model_33

Geoff

What does aplay -l report?

Geoff

I did find some fonts that seem to work with some scripts :-

https://dev1galaxy.org/viewtopic.php?pid=8362#p8362

Geoff

On my laptop I am offered 2 versions of lsb_release, 9.20150917 and 4.1+devuan2

$ apt-cache policy 'lsb-release'
lsb-release:
  Installed: 9.20150917
  Candidate: 9.20150917
  Version table:
 *** 9.20150917 100
        100 /var/lib/dpkg/status
     4.1+devuan2 500
        500 https://pkgmaster.devuan.org/merged ascii/main amd64 Packages

while the desktop only knows about 4.1+devuan2. I wonder whether this is from the history as the laptop went from Debian testing to Devuan ASCII, while the desktop went from Debian Jessie to Devuan Jessie to ASCII. /usr/bin/lsb_release on the laptop dates from Aug 2015.

Geoff

Meanwhile, back on my laptop

python -v /usr/bin/lsb_release -a

fails to run, while

python3 -v /usr/bin/lsb_release -a

does work, using /usr/lib/python3/dist-packages/lsb_release.py

This version 3 version does not appear to be Devuan specific and returns :-

No LSB modules are available.
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 9 (n/a)
Release:	9
Codename:	n/a

Geoff

Yes, I have the same contents in the files in /etc devuan_version, issue & os-release that you report as well as "9" in debian_version. I thought that I saw on DNG that one only needs to give the command apt-get update to make things correct, but I have also done an apt-get dist-upgrade, which has not corrected my laptop.

Geoff

Logging

I now have both my machines running OpenRC and have logging turned on in /etc/rc.conf with rc_loger="YES". As I have been playing around with OpenRC I have been looking at /var/log/rc.log and it is quite interesting.

Each chunk of the output has timestamps aroung it in the style :-

rc sysinit logging started at Wed May 30 08:21:28 2018
...
rc sysinit logging stopped at Wed May 30 08:21:28 2018

The chunks seem to include sysinit, default and off. This is probably quite reasonable although there is an oddity, in that the rc off chunks are repeated 3 times in all, Twice next to each other and then again after a reboot, following the rc sysinit chunk, with the actual times being repeated, followed by a repeat of the sysinit chunk! Only the first appearance of the off chunk actually has the closing timestamp. I wonder whether there is a problem with doing some of the logging when the disk may not be available and the info is stored in memory and then cleared to disk later, but it seems to be carried over a boot from cold! This is not a major problem, although it is a bit untidy and rc.log will grow quicker that necessary.

If the time stamps are to be believed then the length of time taken for each stage would appear to be

sysinit <1 sec.
default ~12 sec.
off     ~4 sec. which includes saving the dependency cache

I have also tried turning on the parallel boot in /etc/rc.conf with rc_parallel="YES". So far this has not caused any hangs. The logging gets a bit more interesting as the messages from the parallel daemons gets interleaved. This is a sort of "you asked for it, you got it"! To help you decipher the logs, each part of a message is prefixed by the name of the service. Is it any faster? Well, looking at the timestamps again :-

sysinit <1 sec.
default ~6 sec.
off     ~1 sec. which still includes saving the dependency cache

So you might think that the boot is 6s faster and shutdown 3s faster. I'm not sure that it is that obvious when you are sat in front of the machine.

Looking at the logs like this, you tend to notice error messages that you might have otherwise missed. I spotted that this line appears a couple of times :-

networking            |/sbin/dhclient-script: 10: [: =: unexpected operator

I assume that this is supposed to be an error on line 10. Having a look at /sbin/dhclient-script and depending on how you count the lines (!) I can see

        while ! { : >> "$file"; } 2>/dev/null; do

but I don't know if this is where or what the problem might be. Anyway dhcp seems to work.

Geoff

What does the OpenRC supervise-daemon look like?

There are references in some of the OpenRC documentation about its own supervise-daemon.
https://github.com/OpenRC/openrc/blob/m … n-guide.md
This would appear to be an alternative to using Runit. I thought that I would have a look to see how it compares.

All that was required to be set up was the init.d file. It is necessary to remove the dependency on runsvdir and the supervisor becomes supervise-daemon. It is also necessary to set up a pid filename as well as the command. Any arguments necessary to make the daemon remain in the foreground are also required. There is more detail in what can appear in the init.d file described in man openrc-run.

# cat << EOF > /etc/init.d/my-bluetooth-2
#!/sbin/openrc-run
name="Bluetooth Daemon"
description="A bluetooth daemon"
supervisor=supervise-daemon
command=/usr/sbin/bluetoothd
command_args_foreground=--nodetach
pidfile=/run/bluetoothd.pid

depend() {
   need mountall rsyslog dbus
}
EOF

To move to this set-up, remove the reference to openrc in /etc/rc.local and then tell OpenRC about the new set-up.

# rc-service my-bluetooth stop
# rc-update delete my-bluetooth default
# rc-update add my-bluetooth-2 default

Now kick it into action :-

# openrc
 * Starting Bluetooth Daemon ...
bluetoothd[5975]: Bluetooth daemon 5.43                     [ ok ]
bluetoothd[5975]: Starting SDP server
bluetoothd[5975]: Bluetooth management interface 1.14 initialized

ps uaxf reports :-

root      5974  0.0  0.0  36292   252 pts/2    S    20:46   0:00 supervise-daemon --start --pidfile /run/bluetoothd.pid /usr/sbin/bluetoothd -- --nodetach
root      5975  0.0  0.0  28228  3956 ?        Ss   20:46   0:00  \_ /usr/sbin/bluetoothd --nodetach

$ cat /run/bluetoothd.pid 
5974

The recorded pid is that of the supervise-daemon rather than the bluetooth daemon.

This requires less setting-up than with runit, as it only requires the file in /etc/init.d, whereas runit also requires the run file in /etc/sv.

I did try killing off the daemon under both Runit and OpenRC supervise-daemon with kill -9 and in both cases the daemon was restarted.

Geoff

I am reporting on my efforts to integrate Runit with OpenRC in a separate thread under DIY :-

https://dev1galaxy.org/viewtopic.php?id=2078

Geoff