Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] Can't enable 66 after migration from s6 (Read 6468 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Can't enable 66 after migration from s6

Reply #30 –
Oh wow, apparently I completely missed that topic. At the time of that thread, dbus-s6 defaulted to regenerating the machine-id everytime the service restarted. However, the default was later changed to not regenerate the id because some applications expect it to always be the same. You can change this in the /etc/s6/config/dbus.conf file of course. Anyways if you're just running the default, it shouldn't be regenerating anything.

Re: Can't enable 66 after migration from s6

Reply #31 –
Quote from: strajder – on
I can provide whatever info is needed to debug the issue if you want to. If not, specifying the start order of dbus strictly before the services depending on it by putting it in a parent tree solves the issue for me, so in that case you can mark this as solved.

Edit: Maybe this topic is related? It deals with dbus and machine-id: https://forum.artixlinux.org/index.php/topic,2016.msg13531.html#msg13531


On my system setup, elogind then dbus gets started before depending services do

Re: Can't enable 66 after migration from s6

Reply #32 –
Quote from: Dudemanguy – on
Oh wow, apparently I completely missed that topic. At the time of that thread, dbus-s6 defaulted to regenerating the machine-id everytime the service restarted. However, the default was later changed to not regenerate the id because some applications expect it to always be the same. You can change this in the /etc/s6/config/dbus.conf file of course. Anyways if you're just running the default, it shouldn't be regenerating anything.
Hmm. I can add a check if it exists

Re: Can't enable 66 after migration from s6

Reply #33 –
File /etc/66/service/dbus has this:
Code: [Select]
[main]
@type = longrun
@version = 0.0.6
@description = "dbus system daemon"
@user = ( root dbus )
@maxdeath = 3
@notify = 4
@options = ( log env )
@timeout-up = 3000

[start]
@build = auto
@execute = (
	execl-toc -S ${socket_name} -m 0755
	foreground { dbus-uuidgen --ensure=/etc/machine-id }
	execl-cmdline -s { dbus-daemon ${cmd_args} }
)

[stop]
@build = auto
@execute = ( s6-rmrf ${socket_name} )

[environment]
cmd_args=!--system --print-pid=4 --nofork --nopidfile
socket_name=!/run/dbus/system_bus_socket


This line is interesting:
Code: [Select]
foreground { dbus-uuidgen --ensure=/etc/machine-id }
From man dbus-uuidgen:
Quote
--ensure[=FILENAME]
           If a filename is not given, defaults to localstatedir/lib/dbus/machine-id (localstatedir is usually /var). If this file exists then it will be validated,
           and a failure code returned if it contains the wrong thing. If the file does not exist, it will be created with a new uuid in it. On success, prints no
           output.
BTW, I just cat-ed /etc/machine-id and /var/lib/dbus/machine-id and they are different. Running lsattr on them reveals they both have only 'e' flag set.

Re: Can't enable 66 after migration from s6

Reply #34 –
On my system (where the suite66 transition worked mostly smooth), /var/lib/dbus/machine-id is a symlink to /etc/machine-id.

I migrated it from Runit, if that's any help.

Re: Can't enable 66 after migration from s6

Reply #35 –
Quote from: capezotte – on
On my system (where the suite66 transition worked mostly smooth), /var/lib/dbus/machine-id is a symlink to /etc/machine-id.

I migrated it from Runit, if that's any help.
Believe it or not, this works! Thank you.

I just did:
Code: [Select]
# rm /var/lib/dbus/machine-id
# ln -s /etc/machine-id /var/lib/dbus
deleted the child tree, enabled all services in default tree, rebooted, and it works. What's more, Viber in firejail also works, just checked. :)

Edit: Spoke too soon. Viber works on my s6 desktop, but now on 66 with the symlink, it doesn't. :(

Edit 2: I guess I could chattr +i /etc/machine-id, then login to Viber again after deleting the profile, but I'm not sure if setting the +i flag will crash dbus. Maybe have the dbus-uuidgen run conditionally?

Re: Can't enable 66 after migration from s6

Reply #36 –
I plan to test out conditional uuidgen in vm as soon as I can

Re: Can't enable 66 after migration from s6

Reply #37 –
This worked for me:
Code: [Select]
[main]
@type = longrun
@version = 0.0.6
@description = "dbus system daemon"
@user = ( root dbus )
@maxdeath = 3
@notify = 4
@options = ( log env )
@timeout-up = 3000

[start]
@build = auto
@execute = (
	execl-toc -S ${socket_name} -m 0755
	foreground { test x${run_uuidgen}==xtrue && dbus-uuidgen --ensure=/etc/machine-id }
	execl-cmdline -s { dbus-daemon ${cmd_args} }
)

[stop]
@build = auto
@execute = ( s6-rmrf ${socket_name} )

[environment]
cmd_args=!--system --print-pid=4 --nofork --nopidfile
socket_name=!/run/dbus/system_bus_socket
run_uuidgen=!false
like that, even Viber works on my laptop with 66 (just checked).

Edit: Scratch that. The conditional doesn't work when run_uuidgen is set to true. :/ Not bash, huh?

Re: Can't enable 66 after migration from s6

Reply #38 –
execline's equivalent of && is the if command, as in:

Code: [Select]
	execl-toc -S ${socket_name} -m 0755
	foreground { if { test ${run_uuidgen} = true } dbus-uuidgen --ensure=/etc/machine-id }
	execl-cmdline -s { dbus-daemon ${cmd_args} }

From what I gathered from reading the 66 docs, you can change the start section to (untested)

Code: [Select]
[start]
@build=custom
@shebang=/bin/bash
@execute=(
[ -S /run/dbus/system_bus_socket ] || exit 1
...
)

To use bash/sh scripts in 66 services (in fact, any language can be used this way).

Re: Can't enable 66 after migration from s6

Reply #39 –
I've added an conditional to dbus. So maybe this will help

Re: Can't enable 66 after migration from s6

Reply #41 –
Unfortunately, this latest fix didn't work. Also, it seems to rely on testing the existence of the file /etc/machine-id, (not sure if the if works either, as I'm not familiar with the language used in the config) when that should already be done by dbus-uuidgen itself. What I had in mind was the call to dbus-uuidgen be driven by a user choice through an environment variable as in capezotte's answer. Applying this:
Code: [Select]
	execl-toc -S ${socket_name} -m 0755
	foreground { if { test ${run_uuidgen} = true } dbus-uuidgen --ensure=/etc/machine-id }
	execl-cmdline -s { dbus-daemon ${cmd_args} }
works, meaning I can start Xorg and my Viber doesn't crash when I set run_uuidgen to anything else than true:
Code: [Select]
[environment]
cmd_args=!--system --print-pid=4 --nofork --nopidfile
socket_name=!/run/dbus/system_bus_socket
run_uuidgen=!false
By default, that part would include run_uuidgen=!true, so dbuis-uuidgen would be called upon every reboot like it should. But if anyone needs to skip it (like I do for now, because I'm required to use Viber by my employer), that would be accomplished by setting it to not true.

Re: Can't enable 66 after migration from s6

Reply #42 –
Odd that it doesn’t work for you. I decided to do it that way so it would only create the machine-id once. Another reason, is so a new user wouldn’t likely have issue with it as they may not know to set uuidgen to true. What you can do as your system may be a special case, is to put the dbus service file in /etc/suite66/service so if I do any updates to it, yours won’t be overwritten. 66 will look for service files in /etc/suite66/service first and if found use that one instead of one in /etc/66

Re: Can't enable 66 after migration from s6

Reply #43 –
I think there has been a misunderstanding. As I said, the service file would already have run_uuidgen set to true by default. It would be an option to prevent running dbus-uuidgen by switching that to false. New user wouldn't have to change anything and dbus-uuidgen would be started on every boot as before. But for those who need to skip it (like myself), setting this to false would provide a way to do that.

By the way, there isn't anything special about "my system", I'm just required to use Viber. Viber on any GNU/Linux system doesn't like changing machine ID, which is a privacy step introduced by Artix team, and which I support, but regrettably have to disable in order to be able to run Viber.

Re: Can't enable 66 after migration from s6

Reply #44 –
Quote from: strajder – on
I think there has been a misunderstanding. As I said, the service file would already have run_uuidgen set to true by default. It would be an option to prevent running dbus-uuidgen by switching that to false. New user wouldn't have to change anything and dbus-uuidgen would be started on every boot as before. But for those who need to skip it (like myself), setting this to false would provide a way to do that.

By the way, there isn't anything special about "my system", I'm just required to use Viber. Viber on any GNU/Linux system doesn't like changing machine ID, which is a privacy step introduced by Artix team, and which I support, but regrettably have to disable in order to be able to run Viber.

Ah yes. Was a bit of misunderstanding

Built new pkg with option true/false. So can change UUIDGEN=false so it doesn’t generate uuidgen and place in protected dir I described in a previous post