The officially official Devuan Forum!

You are not logged in.

#1 Re: Desktop and Multimedia » [SOLVED] ASCII: can't run ObConf in openbox » 2018-11-09 10:11:05

I use openbox with LXDE and obconf just works. I see that openbox recommends obconf, so it might be that it has not been installed. It should be in /usr/bin/obconf if it has been installed.

Geoff

#2 Re: Hardware & System Configuration » what deletes contents of /tmp directory? [SOLVED] » 2018-11-08 16:48:27

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

#3 Re: Hardware & System Configuration » what deletes contents of /tmp directory? [SOLVED] » 2018-11-08 14:33:02

GNUser wrote:

Geoff, I was sloppy in post #2.

But not as sloppy as me! :-)

Geoff

#4 Re: Hardware & System Configuration » what deletes contents of /tmp directory? [SOLVED] » 2018-11-08 13:27:38

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

#5 Re: Hardware & System Configuration » what deletes contents of /tmp directory? [SOLVED] » 2018-11-08 13:24:38

Whoops! I got the wrong file!

grep tmp /etc/rcS.d/S08checkroot-bootclean.sh 
	# Clean /tmp, /run and /run/lock.  Remove the .clean files to
	rm -f /tmp/.clean /run/.clean /run/lock/.clean

Sorry!

Geoff

#6 Re: Hardware & System Configuration » what deletes contents of /tmp directory? [SOLVED] » 2018-11-08 13:22:53

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

#7 Re: Hardware & System Configuration » error: no symbol table - Grub error HOWTO fix » 2018-10-12 09:33:23

aitor wrote:
grub-install --root-directory=/tmp/mnt /dev/sda

Should that be boot-directory rather than root-directory? I can find no mention of root-directory in the documentation.

Geoff

#8 Re: Installation » Services start issue » 2018-09-04 10:08:45

ralph.ronnquist wrote:

Obviously the Unix idea is the right way, and the others are merely weak attempts of obfuscation.

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

For some reason, the fourth option of LF+CR never took hold, even though that's really the mechanical sequence that got implemented in type writers, and probably the "safest" motion for a ribbon printer, which otherwise might smudge the printing.

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

#9 Re: Installation » [Solved] Permisison issue with winecfg » 2018-09-03 09:16:18

golinux wrote:

the % always puzzled me so you are not alone.

man sudoers suggests that you must put a "%" in front of a group name, presumably to identify it as such. If the group is a numeric ID then you use "%#".

Geoff

#13 Re: Installation » repository changed its 'Origin' value [SOLVED] » 2018-06-04 14:52:24

I have now forced the version of lsb-release on the laptop to be 4.1+devuan2 and it now gives the correct answer. I also noticed that lsb-base was on version 9, so I have also forced that one as well.

Geoff

#14 Re: Installation » repository changed its 'Origin' value [SOLVED] » 2018-06-04 14:32:43

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

#15 Re: Installation » repository changed its 'Origin' value [SOLVED] » 2018-06-04 14:14:12

So, on my desktop machine, lsb_release has at its first line :-

#! /usr/bin/python -Es

while my laptop has :-

#! /usr/bin/python3 -Es

I wonder why they are different! And which is the correct one! Presumably the one which gives the correct answer, which is the one that runs Python 2.7 rather than 3.

Geoff

#16 Re: Installation » repository changed its 'Origin' value [SOLVED] » 2018-06-04 14:08:39

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

#17 Re: Installation » repository changed its 'Origin' value [SOLVED] » 2018-06-04 13:29:31

It seems that lsb-release is written in Python, although the part in /usr/bin/lsb_release only really calls some library stuff. If you run

python -v /usr/bin/lsb_release -a

then you can see the bits that get pulled in, which includes

/usr/lib/python2.7/dist-packages/lsb_release.pyc matches /usr/lib/python2.7/dist-packages/lsb_release.py

Looking at /usr/lib/python2.7/dist-packages/lsb_release.py

it seems that the mapping of release number to codename is hard coded for jessie and ascii, so that if it were to find version 9 then it would think it is unknown. I have not yet figured out how it discovers the version number.

Geoff

#18 Re: Installation » repository changed its 'Origin' value [SOLVED] » 2018-06-03 15:34:22

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

#19 Re: Installation » repository changed its 'Origin' value [SOLVED] » 2018-06-03 10:11:30

I have performed an apt-get update on both my ASCII machines. On my desktop, it corrected the information from lsb_release -a so that it now provides Devuan, 2, ascii. On my laptop I have got the following :-

# apt-get update
Get:1 https://pkgmaster.devuan.org/merged ascii InRelease [22.2 kB]
Get:2 https://pkgmaster.devuan.org/merged ascii-backports InRelease [22.3 kB]
Get:3 https://pkgmaster.devuan.org/merged ascii-proposed-updates InRelease [22.3 kB]
Get:4 https://pkgmaster.devuan.org/merged ascii-security InRelease [21.6 kB]
Get:5 https://pkgmaster.devuan.org/merged ascii-updates InRelease [22.2 kB]
Get:6 https://pkgmaster.devuan.org/merged ascii-backports/main amd64 Packages [359 kB]
Get:7 https://pkgmaster.devuan.org/merged ascii-security/main amd64 Packages [357 kB]
Fetched 827 kB in 0s (841 kB/s)                             
Reading package lists... Done

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

Neither of the machines is a fresh install and have come via Debian originally, although by different routes. It looks as though there is still some hangover from Debian on the laptop.

Geoff

#20 Re: Hardware & System Configuration » Converting to OpenRC » 2018-05-30 14:23:36

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

#21 Re: Hardware & System Configuration » Converting to OpenRC » 2018-05-28 14:10:50

Also in the above mentioned thread on integrating Runit with OpenRC, I have also looked at OpenRC's built-in supervise-daemon.

Geoff

#22 Re: DIY » Integrating Runit with OpenRC (or not... ;-) » 2018-05-28 14:07:11

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

#23 Re: DIY » Integrating Runit with OpenRC (or not... ;-) » 2018-05-21 13:15:32

A real service

I decided to use bluetoothd as my first real test because breaking it would not stop my system from working!

With Runit under SysVinit

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

The directory associated with a service would typically be e.g. /etc/sv/bluetoothd

# v /etc/sv/bluetoothd/
total 20
drwxr-xr-x 4 root root 4096 Dec  8 16:43 ./
drwxr-xr-x 7 root root 4096 Dec 20 16:00 ../
drwxr-xr-x 3 root root 4096 Dec  8 16:43 log/
-rwxr-xr-x 1 root root   57 Dec  8 16:37 run*
drwx------ 2 root root 4096 May 15 14:56 supervise/

where I set up run and log/ while supervise is set up and used by runit.

The contents of /etc/sv/bluetoothd look like this :-

mkdir -p /etc/sv/bluetoothd/log
cd /etc/sv/bluetoothd
cat << EOF2 > run
#!/bin/sh
exec 2>&1
exec /usr/sbin/bluetoothd --nodetach
EOF2

cat << EOF3 > /log/run
#!/bin/sh
exec chpst -ulog svlogd -tt /var/svlogd/bluetoothd
EOF
chmod a+x run log/run

In order to activate it a link would be added to /etc/service, although in ASCII this is typically a link to /etc/runit/runsvdir/default/. runsvdir will be scanning this directory and start services in there. This is the scan directory.

With Runit integrated under OpenRC it uses a separate scan directory /run/openrc/sv which is a tmpfs. OpenRC looks after putting links into this scan directory, using its own directory /etc/runlevels to keep track of what should be run. /etc/runlevels/default is perhaps the equivalent of /etc/rc2.d under SysVinit.

Whether OpenRC uses Runit or not is controlled by the start-up files in /etc/init.d

I suspect that it is best to leave distributed init.d files alone and create our own version, so that it won't be over-written during an upgrade. I will create my-bluetooth in init.d using the bluetoothd set-up I had created earlier. I based the dependencies on /etc/init.d/bluetooth.

as root:-

cat << EOF > /etc/init.d/my-bluetooth
#!/sbin/openrc-run
description="A bluetooth daemon"
supervisor=runit
runit_service=/etc/sv/bluetoothd

depend() {
   need mountall rsyslog dbus runsvdir
}
EOF
chmod a+x /etc/init.d/my-bluetooth

Turn off bluetoothd directly under OpenRC

# rc-update delete bluetooth default
 * service bluetooth removed from runlevel default

# rc-service bluetooth status
[ ok ] bluetooth is running.
# rc-service bluetooth stop
[ ok ] Stopping bluetooth: /usr/sbin/bluetoothd.
# rc-service bluetooth status
[FAIL] bluetooth is not running ... failed!

Now try my-bluetooth

# rc-service my-bluetooth start
 * Caching service dependencies ...
 * Found a solvable dependency loop: cryptdisks a> umountfs u> hwclock.sh a> checkroot n> cryptdisks-early a> lvm2 u> cryptdisks.
 * Found a solvable dependency loop: cryptdisks a> umountfs u> hwclock.sh a> checkroot n> cryptdisks.
 * Found a solvable dependency loop: cryptdisks a> umountfs u> hwclock.sh a> checkroot n> cryptdisks-early n> cryptdisks.
 * Solving the loop by breaking umountfs u> hwclock.sh.
 * Solving the loop by breaking lvm2 u> cryptdisks.            [ ok ]
 * Starting my-bluetooth ...
 * Failed to start my-bluetooth                                [ !! ]
 * ERROR: my-bluetooth failed to start
# rc-service my-bluetooth status
run: /run/openrc/sv/bluetoothd: (pid 5468) 87s; run: log: (pid 5467) 87s
#ps uaxf
...
root      3140  0.0  0.0   4216  1072 ?        S    13:52   0:00 /usr/bin/runsvdir -P /run/openrc/sv log: .....................
root      3173  0.0  0.0   4064   648 ?        Ss   13:52   0:00  \_ runsv test-service
daemon    3174  0.0  0.0   4292  1568 ?        S    13:52   0:00  |   \_ /bin/sh /home/user1/test/test-daemon
daemon    5543  0.0  0.0   4200   636 ?        S    15:14   0:00  |       \_ sleep 60
root      5466  0.0  0.0   4064   664 ?        Ss   15:10   0:00  \_ runsv bluetoothd
log       5467  0.0  0.0   4208   680 ?        S    15:10   0:00      \_ svlogd -tt /var/svlogd/bluetoothd
root      5468  0.0  0.0  28228  3928 ?        S    15:10   0:00      \_ /usr/sbin/bluetoothd --nodetach

/var/svlog/bluetoothd/current reports :-

2018-05-20_14:10:24.52202 bluetoothd[5468]: Bluetooth daemon 5.43
2018-05-20_14:10:24.52232 bluetoothd[5468]: Starting SDP server
2018-05-20_14:10:24.52431 bluetoothd[5468]: Bluetooth management interface 1.14 initialized
2018-05-20_14:10:24.52443 bluetoothd[5468]: Failed to obtain handles for "Service Changed" characteristic
2018-05-20_14:10:24.52462 bluetoothd[5468]: Sap driver initialization failed.
2018-05-20_14:10:24.52464 bluetoothd[5468]: sap-server: Operation not permitted (1)

I can also see it from my phone.

The next thing is to set it to be part of runlevel default.
It seems to be a bit problematical to stop this manually started instance as is thinks it is not running, so ...

# rc-service my-bluetooth start
 * Starting my-bluetooth ...                               [ ok ]
# rc-service my-bluetooth status
run: /run/openrc/sv/bluetoothd: (pid 5468) 1334s; run: log: (pid 5467) 1334s
# rc-service my-bluetooth stop
 * Stopping my-bluetooth ...                               [ ok ]

Now add it to default and give it a prod!

# rc-update add my-bluetooth default
 * service my-bluetooth added to runlevel default
# openrc
[ ok ] Stopping bluetooth: /usr/sbin/bluetoothd.
 * Starting my-bluetooth ...
 * Failed to start my-bluetooth                           [ !! ]
 * ERROR: my-bluetooth failed to start
 * Starting test-service ...                              [ ok ]

Both of these services are running. As bluetooth started first and test-service, which was second has reported that it started, it might be worth making bluetooth depend on test-service! Unfortunately this does not work. I tried several methods to run openrc a bit later, but none worked until I hit on running it from rc.local after a sleep, while backgrounding it, so that it would not delay the boot.

Edit /etc/rc.local and add a line before the end so that it reads :-

(sleep 5 ; /sbin/openrc)&
exit 0

I haven't tried adjusting the sleep time from 5 seconds as it just worked, but maybe it could be less or on a slow machine it may need to be longer.

# tail -25 /var/log/rc.log 
[....] Starting LVM2 metadata daemon: lvmetad[ ok .
[....] Starting LVM2 poll daemon: lvmpolld[ ok .
[....] Starting X display manager: lxdm[ ok .
 * Starting runsvdir ...
 [ ok ]
 * Starting my-bluetooth ...
 * Failed to start my-bluetooth
 [ !! ]
 * ERROR: my-bluetooth failed to start
[....] Starting NTP server: ntpd[ ok .
[....] Starting OpenBSD Secure Shell server: sshd[ ok .
[....] Setting sysfs variables...[ ok .
[....] Starting Network connection manager: wicd[ ok .
[....] Not running within Xen or no compatible utils ...[warn (warning).

rc default logging stopped at Mon May 21 11:22:27 2018


rc default logging started at Mon May 21 11:22:32 2018

 * Starting my-bluetooth ...
 [ ok ]

rc default logging stopped at Mon May 21 11:22:32 2018

Although this is a crude hack to work around the start-up bug, it this seems to work ok. The service does start from the initial attempt, but it does not seem to be recorded correctly. The calling of openrc gets it to try and start it again, which tidies up the housekeeping IIUC.

Geoff

#24 Re: Hardware & System Configuration » Converting to OpenRC » 2018-05-19 16:20:42

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

#25 Re: DIY » runit as a process supervisor » 2018-05-19 16:18:31

I am reporting my efforts to get Runit integrated with OpenRC in a separate thread :-

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

Geoff

Board footer

Forum Software