[Solved] DWM not opening again brave in sandbox

Succulent of your garden · 2024-10-21 22:24:13

Hi !

Recently I'm making a transition in a pc from wayland to xorg, and making my dwm setup. In the firsts boot ups my keybinding for launching brave works well. Here it is from the config.h file in the Key keys array:

  { MODEKEY,    XK_B,    spawn,    {.v = (const char*[]){ "firejail", "brave", "--store-password=basic", NULL } } },

As you can see, I'm using firejail to sandbox the browser, and using the brave-bin AUR package.

It's seems like brave doesn't provide a good support for linux in general, but in my Hyprland setup the sandoxing just works well in the same pc using that command. The flag --store-password is because of the brave default intentions to have a crypto wallet. Since I just don't use the crypto wallet, I just put it in basic mode, otherwise the browser starts to complain to create a password-storage mode for the brave wallet before launching it by a gui request.

My dwm in the first launch of the browser just works. So I just use the super key in my case + b and brave just launched well. But if I close the browser, then the second attemp (and so on) of launching the browser starts to complain with the gui request of the wallet password-storage. If you just click cancel in the gui the browser never launches. I think if you do this many times there is a step where nothing happens, even the annoying gui.

This is my xinitrc btw:

xset -dpms
feh --bg-scale ~/wallpapers/my-wallpaper.png
picom -b &
dwmblocks &
while true: do
      dbus-launch dwm 2> ~/.dwm.log
done

I'm not sure what is going wrong, the only patch applied is dwmblocks. There is something more that should I do to xorg or with dbus ? any help in troubleshooting will be appreciated.

Btw, do you reccomend another sandoxing program ?
Have a nice week!

Last edited by Succulent of your garden (2024-10-24 15:02:46)

V1del · 2024-10-22 08:42:42

Don't ever use dbus-launch unless you actually have a reason to and know why. Get rid of the dbus-launch and instead fix your .xinitrc to properly initialize an user session: https://wiki.archlinux.org/title/Xinit#xinitrc (note the "Note" boxes)

Succulent of your garden · 2024-10-22 20:45:51

Hi V1del thanks for the reply.

So this should be like this right ?

xset -dpms
feh --bg-scale ~/wallpapers/my-wallpaper.png
picom -b &
dwmblocks &
while true: do
      exec dwm 2> ~/.dwm.log
done

I'm not quite sure if it is needed this line from the wiki in xinit

cp /etc/X11/xinit/xinitrc ~/.xinitrc

Since I'm not going to use xterm twm and the xorg-xclock, It seems not necessary. Also the Suckless page say that you can just start using it by just exec dwm in .xinitrc. I'm not quite sure if what I'm doing is correct and safe, since you mention the need to initialize an user session. I assume that startx do that, but not quite sure now.

Last edited by Succulent of your garden (2024-10-22 20:47:41)

seth · 2024-10-22 21:24:16

No. See the link again. One of the notes says what to include at least.
Also

while true: do

should™ get you a syntax error? and also won't work because dwm will replace the xinit process and the loop stops immediately.

Do you actually start the session w/ xinit or startx?

loginctl session-status

Succulent of your garden · 2024-10-22 21:57:57

Hi seth thanks. The while loop is a hacky thing to shutdown dwm and restart quickly without going to tty, and see the ricing more quickly.

It doesn't send me any syntax error, and dwm is working well after dbus-launch deleted from the script. But always had launch well.

I'll read the xinit page again tomorrow, too tired to understandt it well today.

seth · 2024-10-22 22:05:12

The while loop is a hacky thing to shutdown dwm and restart quickly without going to tty

I understand what it's supposed to do, but it won't.
Open an xterm and run

while true; do exec xterm; done # nb. the ";" instead of the colon ":"

Then close the second xterm…

Succulent of your garden · 2024-10-23 13:25:35

HI seth thanks for your replies. Now that I'm less sleepy i read this in the xinit wiki:

Note: At the very least, ensure that the last if block in /etc/X11/xinit/xinitrc is present in your ~/.xinitrc file to ensure that the scripts in /etc/X11/xinit/xinitrc.d are sourced.

So after my facepalm now I had the file but with the xterm last part deleted, and inserted my programs with & and dwm. And now the scripts fails to launch because of the while do loop as you said. I guess it's a syntax error, but without the deffault xinit file in the .xinitrc the script does starts and works.

I have two questions because of that. What does exactly the IFs from the /etc/X11/xinit/xinitrc ? It's a good idea to delete all except the last one if ? I'm guessing that now my setup is right with proper user session, since loginctl session-status shows active and being well, but if you think there is something more to be done it will be appreciated, a little dwm newbie here.

there is a way to make the loop working now , so I can just be ricing more quickly ? Currently the script works but without using the loop section, just using exec dwm 2> ~/.dwm.log

Last edited by Succulent of your garden (2024-10-23 13:28:46)

seth · 2024-10-23 13:47:20

Don't exec dwm, https://man.archlinux.org/man/core/man-pages/exec.1p.en
Nothing after it will ever be executed.

The default xinit sources various other files, most notably /etc/X11/xinit/xinitrc.d/50-systemd-user.sh which imports the session environment.
In doubt post your udpated xorg log and please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Succulent of your garden · 2024-10-24 14:59:21

hi seth thanks for the reply.

Here are the logs:

paste.ofcode.org/p8bfLvk9ZRFVWqUdsA9Gww

I check the logs, and the all the info up to line 99 is just informational data. I'm not sure if the errors are "really" errors. But there is a couple of warnings.

Since the main issue was solved I marked the topic as solved.

Cheers

Last edited by Succulent of your garden (2024-10-24 15:01:49)

seth · 2024-10-24 15:32:11

seth's fingers wrote:

In doubt post your udpated xorg log

but seth's brain wrote:

In doubt post your udpated xinitrc

Succulent of your garden · 2024-10-25 11:40:26

paste.ofcode.org/rutekJFDMLhmgJn7Qbqpkg

Sorry for the extra numbers, doesn't have too much time to change the alias of cat == bat

Nevertherless thanks for your help.

Last edited by Succulent of your garden (2024-10-25 11:41:06)

seth · 2024-10-25 14:47:59

Sorry for the extra numbers, doesn't have too much time to change the alias of cat == bat

That's ok w/ me but
1. what does cat have to do w/ uploading a file?
https://porkmail.org/era/unix/award#cat
2. you want "bat" to behave like "cat" if the stdout isn't a tty to avoid unpleasant surprises when actually conCATenating stuff

Succulent of your garden · 2024-10-28 11:33:03

seth wrote:

Sorry for the extra numbers, doesn't have too much time to change the alias of cat == bat
That's ok w/ me but
1. what does cat have to do w/ uploading a file?
https://porkmail.org/era/unix/award#cat
2. you want "bat" to behave like "cat" if the stdout isn't a tty to avoid unpleasant surprises when actually conCATenating stuff

1.

Of course, as Heiner points out, using cat on a single file to view it from the command line is a valid use of cat (but you might be better off if you get accustomed to using less for this instead).

I forget the existence of less i guess, and I was in a hurry up time when I wrote the post, and since i really like my terminal programs, I usually relly in terminal programs to do my stuff insteaf of gui programs. Maybe you could do something with lf but i'm not so pro using it right now. I really like the terminal as you can see

So does the .xinitrc is okey ?

Thanks for you help btw.
Cheers

seth · 2024-10-28 13:11:36

So does the .xinitrc is okey ?

Yup. Though it doesn't loop dwm.

I'd maybe not use a WM as session keeping process anyway but preferably some non-interactive dummy.
WIth the loop, if you screw up and dwm crashes on startup, you'll end with a live-locked borderline unusable system.

Succulent of your garden · 2024-10-29 13:29:57

thanks seth for you help but:

I'd maybe not use a WM as session keeping process anyway but preferably some non-interactive dummy

What do you mean by that ? I'm really curious

The loop thing I'll be using it just to ricing more faster, after the ricing is done, I'll wrote the dwm launch without the loop because of what are you saying.

seth · 2024-10-29 13:57:41

The X11 session will live as long a the xinit process lives.
So if the final executable (whether it replaces xinit or not) never terminates, X11 won't terminate and you can kill the server whenever you want.
"sleep infinity" would do.
Or you fork that, log the PID and https://man.archlinux.org/man/core/man-pages/wait.1p.en for its termination.
Then you can terminate the session by killing that process (or xinit)

Basic example:

…
dwm &
sleep infinity &
dornroeschen=$!
echo $dornroeschen > /tmp/.$USER.xsession.pid
wait $dornroeschen # wait until the PID from /tmp/.$USER.xsession.pid gets killed
# do clean-up stuff

To terminate the session:

kill $(</tmp/.$USER.xsession.pid)

Since wait isn't prone to crash or so, you can do to your WM whatever you want.
You can also skip the wait stuff but fill have to fish the relevant process out of process list (check pkill options) rather than putting it into a file.

Succulent of your garden · 2024-10-30 14:28:26

Thaks Seth for your help. But I'm not quite sure how to do the implementation of this:

You should do it like this ? :

…
dwm &
sleep infinity &
dornroeschen=$!
echo $dornroeschen > /tmp/.$USER.xsession.pid
wait $dornroeschen # wait until the PID from /tmp/.$USER.xsession.pid gets killed
# do clean-up stuff
kill $(</tmp/.$USER.xsession.pid)

Since you get the PID of the sleep infinity, I assume that you should get also the tree for the xinit process. Since you set to wait, I guess you should kill the user session with the last command. I'm right ? That should kill the tree process that includes the sleep inifinity process in the .xinitrc , but that also should be included in the .xinitrc last command [the kill command] ?

What is the benefit of doing this ? I'm really curious.

Once again, thanks for your help. I'm learning a lot of Xorg here I guess

seth · 2024-10-30 15:03:28

I assume that you should get also the tree for the xinit process.

Not necessarily. Why would you?

When xinit terminates at the end of the xinit script, the session terminates, the x11 server stops and all your GUI clients terminate.
If the session keeping process is your WM but you're also messing around with it (applying pateches etc) you increase the risk of an "accidental" session end (ie. the WM crashes and all your GUI dies with it, including maybe some usaved work)
So the idea is to make the session independant of the WM and hook it onto something more reliable.

If you instead just loop the WM
1. you may end up w/ an infinite loop of WM restarts, crashes on start, restarts, crashes on restart, restarts…
2. You cannot properly terminate the session by killing the WM but in doubt would have to kill xinit what precludes the execution of any exit commands

You can discriminate on 2 by conditioning the loop on the exit status of the WM

ret=$?
[ $ret = 0 -o $ret = 15 ] && exit

Succulent of your garden · 2024-10-31 14:32:23

Ohh I see many thanks Seth for the explanaition

Not necessarily. Why would you?

Because it is in the same xinitrc, so if for some reason the WM crashes, I assume that the xinitrc script goes on and finish the session propperly in any case. But not so sure, because if the WM send a signal diferent than zero, maybe the script would stop.

But what do you think is the best implementation of this session manager outside of the WM ? I could just put it right in the end part of the xinitrc ?

seth · 2024-10-31 18:44:42

I could just put it right in the end part of the xinitrc ?

Yes, of course. You're just looking for some™ process that you can terminate in a controlled fashion that that allows you to mess around w/ your WM.
Everything else is details and personal preference.

if the WM send a signal diferent than zero, maybe the script would stop.

No. Not unless you "set -e".

Succulent of your garden · 2024-11-01 10:49:27

Thanks very much Seth for you help in this thread.

Have a nice wochende.

Arch Linux

#1 2024-10-21 22:24:13

[Solved] DWM not opening again brave in sandbox

#2 2024-10-22 08:42:42

Re: [Solved] DWM not opening again brave in sandbox

#3 2024-10-22 20:45:51

Re: [Solved] DWM not opening again brave in sandbox

#4 2024-10-22 21:24:16

Re: [Solved] DWM not opening again brave in sandbox

#5 2024-10-22 21:57:57

Re: [Solved] DWM not opening again brave in sandbox

#6 2024-10-22 22:05:12

Re: [Solved] DWM not opening again brave in sandbox

#7 2024-10-23 13:25:35

Re: [Solved] DWM not opening again brave in sandbox

#8 2024-10-23 13:47:20

Re: [Solved] DWM not opening again brave in sandbox

#9 2024-10-24 14:59:21

Re: [Solved] DWM not opening again brave in sandbox

#10 2024-10-24 15:32:11

Re: [Solved] DWM not opening again brave in sandbox

#11 2024-10-25 11:40:26

Re: [Solved] DWM not opening again brave in sandbox

#12 2024-10-25 14:47:59

Re: [Solved] DWM not opening again brave in sandbox

#13 2024-10-28 11:33:03

Re: [Solved] DWM not opening again brave in sandbox

#14 2024-10-28 13:11:36

Re: [Solved] DWM not opening again brave in sandbox

#15 2024-10-29 13:29:57

Re: [Solved] DWM not opening again brave in sandbox

#16 2024-10-29 13:57:41

Re: [Solved] DWM not opening again brave in sandbox

#17 2024-10-30 14:28:26

Re: [Solved] DWM not opening again brave in sandbox

#18 2024-10-30 15:03:28

Re: [Solved] DWM not opening again brave in sandbox

#19 2024-10-31 14:32:23

Re: [Solved] DWM not opening again brave in sandbox

#20 2024-10-31 18:44:42

Re: [Solved] DWM not opening again brave in sandbox

#21 2024-11-01 10:49:27

Re: [Solved] DWM not opening again brave in sandbox

Board footer