Artix Linux Forum

No, you shouldn't modify /etc/runit/1 script.

In runit, there is a special script /etc/rc.local. It executes after stage 1 is finished and before stage 2 is started. You can add your one-shot boot commands there. E.g. I use this file to run cpupower in order to adjust frequency governors for my CPU.

Whilst I do not know if modifying /etc/runit/1 to execute your own commands is a good idea (I'm gonna guess no but, I really don't know), but do you need to run it at boot?

I can't think of any use cases where you might need bluetooth before you log on/start X?

Is there any reason you can't just add the command:

Code: [Select]

rfkill unblock &

To your .xinitrc/.xprofile so that it is executed as your X session starts?

Thanks for the replies!

I had indeed found my way to the /etc/rc.local file, so I'll keep my current solution in place then.

Personally, I don't like to have startup commands that don't require graphics depend on having X running. Two personal use cases where this is inconvenient:

• I frequently find myself working in tmux directly from a tty, mostly to check running jobs on a remote machine. Whilst doing so, I do like to stream music (to bluetooth speakers), using either a headless or a terminal-based musing application.
• Sometimes I boot my computer simply to play music (with sound output through bluetooth speakers). In that case, I want to just hit the on button on my computer and be able to control the music from my phone or any other machine on the network without any further action required on the streaming machine.

For both of these use cases it's problematic to have startup commands depend on X server initialization. (For completeness: I'm definitely not an expert, but I love to learn and try new things with my graphics setup. Hence, it's not uncommon for me to break something and therefore I prefer to boot into a tty and manually start X when I need it.)

Thanks again and please share any thoughts you might have on the above! Perhaps I'm making things unnecessarily complicated for myself and if so I'd gladly hear about it.

I must say that is quite the unique workflow you have there, I primarily use the terminal and curses based applications and I still start  an X session (probably why I keep getting distracted when I should be writing code lol), I can see why you don't want to put it in .xinitrc.

Although it appears that /etc/rc.local is probably the way to go, you could also put the rfkill unblock command in your login shell's profile (.zprofile, .bash_profile, etc) for a comparable effect?

I don't use tmux much though, so I may be mistaken, but tmux sources the shell profile everytime you bring up a new terminal right? So I guess there is some theoretical overhead?

Regardless, I'm glad you got your answer and I learned something new.

Just to add: with suite66 (as opposed to runit), users can set up services which use regular user (their own) UIDs.

crontab is another possibility.

Tmux acts as a terminal emulator for the shell inside it (pardon my terminology if it's not correct), so indeed the shell's source files are read each time tmux spawns a new shell process. Also, it would appear strange to me to have one-shot commands for the setup of wireless connectivity in a shell source file (since it's not any particular shell that requires the setup, it's the whole system). Either way, /etc/rc.local appears to do the job!

I fail to understand how having user services helps to execute one-shot commands during system boot, could you explain this further?

Now that I know about /etc/rc.local now I kind of want something custom to run at startup just to do it haha.

There are "oneshot" services in s6 and 66.