[SOLVED] Question about update-rc.d

greenjeans · 2024-12-10 02:30:54

Sorry, another noob question.

I have disabled some startup services using update-rc.d like this:

update-rc.d cups disable

So in the absence of a program to enable/disable startup services, i'd like to make a simple script with a menu entry to re-enable them with a click.

My question is can you do multiple item with the same command or do you need to do them one at a time? Was hoping I could do:

update-rc.d cups bluetooth cups-registryd enable

And have them all be re-enabled.

Can't seem to find an answer in documentation or online.

RedGreen925 · 2024-12-10 08:30:03

Well just chain them together like any other commands you can do.

update-rc.d cups enable; update-rc.d bluetooth enable; update-rc.d cups-registryd enable

zeus@9600k:~$ ls ; pwd ; whoami
bin      Documents  mbox   Pictures  rtorrent  Templates
Desktop  Downloads  Music  Public    src       Videos
/home/zeus
zeus

That will execute each command one after the other when used on the command line, like I show above.

Last edited by RedGreen925 (2024-12-10 08:31:35)

nixer · 2024-12-10 13:44:37

Just a rambling thought here... wanted to make sure you knew about sysv-rc-conf.

in the absence of a program to enable/disable startup services

Maybe I am misinterpreting what you are trying to do, but have you used sysv-rc-conf ?

apt install sysv-rc-conf

And then as root from the terminal:

sysv-rc-conf

It will handle the "update-rc.d" commands for you before making the final.iso build, and it certainly is not a hard program to master in order to restart the services later on. Maybe make a small script to start the program in a terminal so that others can toggle the start/stop of the services at boot? It is a handy little program that I have used many, many times in years past.

Hope this helps.

greenjeans · 2024-12-10 14:45:35

Thanks to both of you! Will give both those solutions a try.

Just want to make it easy for users to re-enable services I have turned off, in an easy way, using a small script, yad dialog and a menu entry to work it.

I used to use BUM-Boot Up Manager which was very simple and worked well in Openbox, but it's long gone now. I have Stacer on my main partition, but it's also no longer maintained, and it's a little too blingy and does too much for what I want to do.

Yad works great with little scripts to make kind of a small faux GUI to do things.

greenjeans · 2024-12-10 22:59:06

Well just chain them together like any other commands you can do.

I though that would likely work, but I always try for brevity of code, even in small lines, was hoping one update-rc.d command would work.

@nixer, gave that a try and also rcconf, and both seem a little fraught with peril for a new user to mess with, it's the kind of thing that 15-20 years ago I would have said "WHOA cool! I can turn all this stuff off and my computer will run really fast now!" Yikes!

The problem with the way I have done it by disabling in rc.d, is that now in session I can't start them with

service foobar start

.

I'm thinking a better way is to use update-rc.d to remove them instead, which should do what I want which is to not start during the boot process, then writing a little script/gui that uses the "service" command to start them up.

Of course that would mean the user would have to manually start them every session which might annoy folks, so thinking of adding to the script an option to re-enable them to autostart every boot if so desired.

Couldn't you get them to autostart this way by moving their scripts into /etc/xdg/autostart ? Seems less of a hassle than using the script to update-rc.d and move them back into rc.d.

They still wouldn't be a part of the main boot process a la rc.d, but instead get loaded when the other /etc/xdg/autostart stuff does after openbox gets loaded. Am I wrong about that?

Thanks for your help y'all, just fine-tuning new iso and trying to make it all an enjoyable easy and seamless process.

EDX-0 · 2024-12-10 23:15:10

update-rc.d is a perl script, you can always set up a wrapper around it, my suggestion for a graphical wrapper is to do it in 2 parts, one part a pure shell script that does the job of taking an action (enable disable) and multiple inputs to distribute them to update-rc.d, so that you can do:
wrapper disable cups bluetooth cups-registryd and then inside the script do something like this:

args=""
# while the number of arguments is greater than 0
while [ "$#" -gt 0 ]; do
    case "$1" in
        enable|disable|defaults|remove|defaults-disable)
            action="$1"
            ;;
        *) args="$args $1"
            ;;
    esac
    shift
done

for service in $args; do
    update-rc.d "$service" "$action"
done

then on your GUI frontend with either yad zenity or the program to display menus and create GUIs of your choice you can take multiple inputs from the user and send them with either sudo -A (ensure a SUDO_ASKPASS program is set, i use ssh-askpass-gnome which is linked on /usr/bin/ssh-askpas) or pkexec run the wrapper script, this ensure that you are protecting the enabling|disabling|removal requiring sudo authentication and that you are authenticating only once for a call to the wrapper so that all the services get the action applied to them instead of having to require an authentication per service to be enabled|disbaled.

Last edited by EDX-0 (2024-12-10 23:21:17)

ralph.ronnquist · 2024-12-10 23:19:43

update-rc.d $service $action

EDIT: I'm pretty sure there is a man page for it...

EDX-0 · 2024-12-10 23:21:52

yeh i noticed i F'ed up badly there, fixed the snippet

greenjeans · 2024-12-11 00:00:33

@EDX-0 Thank you! That's a good part of what I wanted to do, using only one authentication for the whole thing. Your post has me on the right track.

At this point though, i'd like to avoid having to use update-rc.d, probably going to test it here shortly moving those services into /etc/xdg/autostart and see if it works as i'd like it to.

EDX-0 · 2024-12-11 00:29:09

what services are we speaking of tho? services that are ran as root or their own user, ie the ones in /etc/init.d OR services to run as part of the user session?

if it is the first then it is okay to use update-rc.d for sysvinit, tho for other inits such as runit or open rc it would just be a question of detecting which init system is being used and instead of using update-rc.d use a different command, the machinery inside the wrapper will remain the same just changing update-rc.d for the corresponding command to the init system.

and speaking of, i jumped the gun and cobbled a script that for the time being i'm calling initctl that wraps update-rc.d and service at https://github.com/eylles/devuan-script … er/initctl

for the second case it i already got a solution of sorts that i've been working on for a while now, it still is alpha software, it works but i still have to implement some more features like separating the main session processes (window manager, status bar, etc) from the more secondary processes (compositor, clipboard manager, network applet, blueman, etc...) and adding singleshot type processes as right now it assumes everything is a daemon of sorts, it is implementen in pure posix shell https://github.com/eylles/shed

greenjeans · 2024-12-11 00:34:44

Wow, just took a quick look at that script and to my (albeit un-trained) eye it looks pretty sweet, if it's okay with you i'll be trying it out here shortly.

The only services i'm concerned with are cups, cups-browsed, and bluetooth, I was trying to do something with just those as they are the only thing I want to disable from the boot process and not autostart, but make them easily available to the user to both start/stop and enable upon startup if they wish.

greenjeans · 2024-12-11 00:38:43

Boot Up Manager that I used back in the jessie days, was really good, you could do all this, and you could view all system services but it would not allow you to modify critical ones.

Sadly you can't even find the source code anymore online, at least I couldn't find it. Need to boot up Vuu-do 1.09 as it has it, can't remember if the executable was binary or a script, if a script may be able to cobble some code out of there.

EDX-0 · 2024-12-11 00:57:22

boot up manager went by as bum in the debian packages https://tracker.debian.org/pkg/bum wonder if there's a way to get the source packages from debian jessie somehow

edit: took me a while but i found something on the archive of old ubuntu releases https://old-releases.ubuntu.com/ubuntu/ … rse/b/bum/

edit 2: so it is a program written in perl, somehow not surprised...

Last edited by EDX-0 (2024-12-11 02:00:49)

greenjeans · 2024-12-11 02:51:20

Sonofagun, your search-fu is way better than mine, didn't even think about Ubuntu archives...searched debian and old references and didn't come up with anything.

Totally not surprising it's perl, some of the best stuff is. I've got a whole bunch of Trizen's other stuff laying around here besides obmenu-generator, that guy does some amazing work in perl.

ETA: lawd, I need to step away from the computer for a bit, or stop drinking this cheap walmart bourbon, I actually did find a source tar.gz two days ago, downloaded and meant to build but forgot about it.

Wow, I'm taking a day off tomorrow, my brain has gone to mush.

Last edited by greenjeans (2024-12-11 02:55:01)

greenjeans · 2024-12-11 03:01:44

libgtk2-perl is a dependency, not in repo, guess I need to find that too to see if it can work.

fsmithred · 2024-12-11 10:17:05

Turn them off in runlevel 2, and then the command to turn them on is

init 3

greenjeans · 2024-12-11 16:43:22

Turn them off in runlevel 2, and then the command to turn them on is
init 3

Wow, perfect, short and sweet, and as per your usual answers to me I just have to know why it works and I just went nuts on reading documentation about init and run levels that I really should have done long ago.

So no issues at all in just switching to run level 3?

fsmithred · 2024-12-11 17:02:12

No issues going to runlevel 3 except you have to be root (or sudo). Just don't try this on a distro that disables the display manager in runlevel 3 (like Refracta desktop isos). In that case you'd have to do 'init 4' or 'init 5' or re-enable the dm in 3.

greenjeans · 2024-12-11 17:13:28

Cool! Yeah this is for the new Vuu-do, so should be fine. Just thinking out loud here as I process new info, but:

So I leave those services disabled in 2.

Leave them enabled them in 3, which is not the default level I boot to, so they won't be running and still won't be started and won't be part of the boot process.

Add a script + yad that switches to run level 3 and then simply invokes the "service" commands to start them.

It's perfect for what I want to do.

Thanks fsmithred and EDX-0, and I won't forget to credit y'all in the script description and such!

fsmithred · 2024-12-11 18:49:51

After 'init 3' command, you don't need to use the service command. They will start (unless you screwed with all the symlinks.) I use sysv-rc-conf to turn services off in runlevel 2.

Not sure what you have in mind, but one way to get root would be to have yad start a terminal that runs su -c 'init 3' and then it'll ask for root pass in the terminal. If you don't want the user to see a terminal, I think you can use yad to take a password and feed it to the command. I'm not as clear on this. See /usr/lib/refracta2usb/functions/function.mkloop around lines 104 and 176 for an example.

greenjeans · 2024-12-11 20:47:05

Nice, i'm going to take look a look thanks! I didn't mess with symlinks, just used update-rc.d to disable those 3 services and have done nothing else, I timed the bootup and it did make it a bit quicker. Booting super-fast off a liveUSB.

Seems like you could take the password in yad, but I usually just make a .desktop for the whole thing, and used to use gksu in the exec line so it the system authorization dialog. Then I can use it in /usr/share/applications, and the obmenu-generator picks it up automatically and gives me a menu entry to activate, or in the .local files for context menu stuff, or both.

Well cool, they're off now already in runlevel 2, I just need to run update-rc.d and give a specific instruction about enabling it in 3.

Man that's even better, I don't even have to really make a script, just a .desktop that pxexec's the "init 3 "command. That's as simple as it gets right there, again, really appreciate the help!

EDX-0 · 2024-12-12 00:21:47

fun i just so happen to have some useful pieces of code on other scripts in https://github.com/eylles/devuan-scripts/ (check every single one, take every piece of code ya want, it is licensed apache2)

in short is to decide if using sudo, sudo with askpass or pkexec:

  has_tty=""
  if tty | grep -qF -e "dev/tty" -e "dev/pts"; then
    has_tty=1
  fi
  if [ -n "$has_tty" ]; then
    sudo command
  else
    if [ -n "$SUDO_ASKPASS" ]; then
      sudo -A command
    else
      pkexec command
    fi
  fi

the content of $SUDO_ASKPASS is usually some program to read a password from the user, some use dmenu or rofi but both programs advice not to use them for password prompts... on my system i set SUDO_ASKPASS to /usr/bin/ssh-askpass which is provided by the ssh-askpass-gnome package, tho i also got a polkit authentication agent for programs like gparted and the like, on my case i run /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 as a daemon inside my user session the program is provided by the policykit-1-gnome package.

greenjeans · 2024-12-12 14:45:06

So I cobbled one together myself late last night, it's not pretty but yet it works right now, just a proof-of-concept for me really, but it works in terminal if you su to root and run it, it also works as a normal user in terminal if I use gksu.sh with the command to run it, and it authenticates and runs properly.

It checks current runlevel first, then spits out a yad dialog giving you level.
Then pops up the dialog that changes runlevels
Afterwards runs "runlevel" again to check new state of runlevel and report that.

ETA: Updated 12-18-24, this one mo bettah. Adds another dialog for if the runlevel was not changed. Cleaned up some useless code. expanded some windows due to title cutoff.

#!/bin/sh

# Copyleft: greenjeans 2024, use as you see fit.
# This is free software with NO WARRANTY. Use at your own risk!
# Depends: yad

# DESCRIPTION:
# Simple script to change run levels. Requires root access so authentication is needed.
# In Vuu-do 5, cups, cups-browsed, and bluetooth are disabled by default in runlevel 2,
# which is the default runlevel you boot into in Devuan/Debian systems. 
# But they are all enabled in runlevel 3, and switching enables and starts the services, 
# and switching back stops/disables them. A .desktop is used to include in menu.
# Can also be used in terminal: levelswitch2 (must be root).

crlev=$(runlevel "$1")

lv=$(echo "$crlev" | awk -F ' ' '{ print $2 }')

yad --fixed --form --width=400 --window-icon=start-here --height=100 --center --borders=10 --button=gtk-ok --title="Runlevel status" --text-align=center --text="
Current runlevel is:  $lv"

rlev=$(yad --fixed --window-icon=start-here --center --borders=10 --form --title="Enable/disable cups and bluetooth" --text-align-center --field="Select from drop-down menu:":CB --text-align=center --wrap --text="
By default Vuu-do boots into runlevel 2, and cups and bluetooth are disabled on startup for faster boot.

Choose below to enable and start them for this session by switching 
to runlevel 3, or turn them back off by switching to run level 2.
---------------------------------------------------------------------------------------------------------------
Note: Default runlevel on boot can be changed by editing /etc/inittab as root.
---------------------------------------------------------------------------------------------------------------

Choose 3 to enable cups and bluetooth, 2 for disable
" 'Choose runlevel!2!3'

)

rl=$(echo "$rlev" | awk 'BEGIN {FS="|" } { print $1 }')

if [ "$rl" = 'Choose runlevel' ]
then echo "runlevel was not changed"
else telinit "$rl"
fi

crlev2=$(runlevel "$1")

lv2=$(echo "$crlev2" | awk -F ' ' '{ print $2 }')

if [ "$lv2" = "$lv" ]
then yad --fixed --form  --width=500 --height=100 --window-icon=start-here --center --borders=10 --button=gtk-ok --title="Runlevel status" --text-align=center --text="
The runlevel has not been changed, current level is:  $lv2"
else yad --fixed --form  --width=400 --height=100 --window-icon=start-here --center --borders=10 --button=gtk-ok --title="Runlevel status" --text-align=center --text="
The current runlevel is now:  $lv2"
fi

And the .desktop:

[Desktop Entry]
Type=Application
Name=Enable/disable cups+bluetooth
Comment=Enable services by changing runlevels
Icon=emblem-system
Exec=gksu.sh levelswitch2
Categories=Settings;

gksu.sh :

# Script to convert gksu to pkexec for extensions already written
# without adding a lot of code to the .desktop command line.
# Usage: "gksu.sh [program]"

#!/bin/bash
if [ -z $1 ]; then
 echo -e "at least 1 argument required!\n" >> /dev/stderr
 exit 1
fi
COMMAND=$1
shift #shift first arg
for ARG in "$@"
do
 if [ -z "$ARGS" ]; then
  ARGS="$ARG"
 else
  ARGS="$ARGS $ARG"
 fi 
done
ARGS=\'$ARGS\'
eval pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $COMMAND $ARGS
exit 0

Last edited by greenjeans (2024-12-18 16:16:49)

greenjeans · 2024-12-13 02:26:32

Marking this as solved.

@EDX-0 still checking out what you're doing, good stuff!

EDX-0 · 2024-12-13 03:21:59

thanks, i either make stuff that is very useful or very useless, no in between.

The officially official Devuan Forum!

#1 2024-12-10 02:30:54

[SOLVED] Question about update-rc.d

#2 2024-12-10 08:30:03

Re: [SOLVED] Question about update-rc.d

#3 2024-12-10 13:44:37

Re: [SOLVED] Question about update-rc.d

#4 2024-12-10 14:45:35

Re: [SOLVED] Question about update-rc.d

#5 2024-12-10 22:59:06

Re: [SOLVED] Question about update-rc.d

#6 2024-12-10 23:15:10

Re: [SOLVED] Question about update-rc.d

#7 2024-12-10 23:19:43

Re: [SOLVED] Question about update-rc.d

#8 2024-12-10 23:21:52

Re: [SOLVED] Question about update-rc.d

#9 2024-12-11 00:00:33

Re: [SOLVED] Question about update-rc.d

#10 2024-12-11 00:29:09

Re: [SOLVED] Question about update-rc.d

#11 2024-12-11 00:34:44

Re: [SOLVED] Question about update-rc.d

#12 2024-12-11 00:38:43

Re: [SOLVED] Question about update-rc.d

#13 2024-12-11 00:57:22

Re: [SOLVED] Question about update-rc.d

#14 2024-12-11 02:51:20

Re: [SOLVED] Question about update-rc.d

#15 2024-12-11 03:01:44

Re: [SOLVED] Question about update-rc.d

#16 2024-12-11 10:17:05

Re: [SOLVED] Question about update-rc.d

#17 2024-12-11 16:43:22

Re: [SOLVED] Question about update-rc.d

#18 2024-12-11 17:02:12

Re: [SOLVED] Question about update-rc.d

#19 2024-12-11 17:13:28

Re: [SOLVED] Question about update-rc.d

#20 2024-12-11 18:49:51

Re: [SOLVED] Question about update-rc.d

#21 2024-12-11 20:47:05

Re: [SOLVED] Question about update-rc.d

#22 2024-12-12 00:21:47

Re: [SOLVED] Question about update-rc.d

#23 2024-12-12 14:45:06

Re: [SOLVED] Question about update-rc.d

#24 2024-12-13 02:26:32

Re: [SOLVED] Question about update-rc.d

#25 2024-12-13 03:21:59

Re: [SOLVED] Question about update-rc.d

Board footer