Managing the services

yars · 11-13-2014, 05:47 AM

Hi everyone,
As we are noticed, the Slackware-way to managing manually the services is simply /etc/rc.d/rc.$SERVICE {start|stop|restart|status} and to make services is running on startup, is enabling or disabling the execution permissions. In an another distributions are provided the service utility, which allows to manage the services just by running 'service $SERVICE start|stop|restart|status'. It is possible to implement 'service' as a shell script, and my question is it really need or not? If need, I can do this.

willysr · 11-13-2014, 06:04 AM

it is possible, but i'm sure for most people who have used Slackware, it won't be necessary for them, since in most cases you enable a service and never turn it off

genss · 11-13-2014, 06:20 AM

if you are lazy, in .bashrc
PATH=/etc/rc.d/:$PATH

then just
rc.service start|stop|whatever

chrisretusn · 11-13-2014, 07:58 AM

Sure it is possible, but why?

/etc/rc.d/rc.whatever doit

_and_

service whatever doit

are pretty much the same to me.

I don't need a service command.

yars · 11-13-2014, 10:43 AM

Quote:

Originally Posted by genss

if you are lazy, in .bashrc
PATH=/etc/rc.d/:$PATH

then just
rc.service start|stop|whatever

Yes, but I'm not sure that don't cause another problems.
To all: thanks you for replies.

NathanBarley · 11-13-2014, 12:15 PM

Quote:

Originally Posted by yars

Yes, but I'm not sure that don't cause another problems.
To all: thanks you for replies.

Are you asking it like a philosophical question?

I think Slackware quite deliberately avoids 'helper' tools like service and chkconfig as part of the KISS principle, but as you can see it's entirely possible to cobble up something similar.

kikinovak · 11-14-2014, 08:13 AM

Quote:

Originally Posted by NathanBarley

Are you asking it like a philosophical question?

I think Slackware quite deliberately avoids 'helper' tools like service and chkconfig as part of the KISS principle

Tools like chkconfig don't make sense on BSD init. Let me take an example.

To activate CUPS on Slackware, it's as simple as:

Code:

# chmod +x /etc/rc.d/rc.cups

When rc.cups is executable, rc.M will start it in the multiuser runlevels, that is 3 and 4. (And 2, but that's only of academic interest.)

Whereas for chkconfig, it allows me to activate CUPS without manually setting/removing a myriad of symlinks:

Code:

# chkconfig --level 2345 cups on

Or simply:

Code:

# chkconfig cups on

As for the service tool, I'm not sure. As far as I can tell, on systems mixing SysV and Upstart, the service command allows some sort of uniformity even if services are managed differently under the hood. Some time ago I had to configure an Ubuntu server, and I was quite puzzled by the mess^^^^^^^diversity of startup management methods.

yars · 11-19-2014, 12:31 PM

Quote:

Originally Posted by NathanBarley

Are you asking it like a philosophical question?

Yes. And the KISS principes does not prevent to have a 'helpers' like liloconfig, xwmconfig, netconfig. This topic also is on a wave of threads about Slackware's initialization system, just to make it more better than it is at this time.

bassmadrigal · 11-19-2014, 01:18 PM

Those 'helpers' are shell scripts to make things easier. That is exactly what the rc.* files are. Shell scripts to make starting and stopping programs easier.

Not trying to start anything here, just pointing out the similarities

Soderlund · 11-19-2014, 01:23 PM

Quote:

Originally Posted by chrisretusn

/etc/rc.d/rc.whatever doit

_and_

service whatever doit

are pretty much the same to me.

Almost alias-able, but not really because of the space.

Code:

$ cat service
#!/bin/sh
/etc/rc.d/rc.$1 $2

dugan · 11-19-2014, 05:25 PM

There's a dialog box in pkgtool where you can check and uncheck which services run on startup.