[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian equivalent to service?



Gregory Seidman wrote:
There is nothing to stop you from making the runlevels behave differently.
Indeed, I use levels 2 and 3 differently on both my server (few services
run until I've mounted my encrypted disks, at which point I switch to
runlevel 3) and my laptop (I want to choose between booting to console or
booting to kdm, depending on whether I'm bringing it up for something quick
and textual or for a real session, when I'm not using suspend/resume).

I know I can set it up differently. I guess I'm hoping for a larger set of useful defaults. 4 levels with the same settings isn't the most useful set of defaults out of the box.

} >2) no 'service ....'instead we use /etc/init.d/service
} >start/stop/restart and AFAICT no 'status'
} } Running both systems, status is another feature that's very useful.

As has been mentioned in this thread, the sysvconfig package supplies the
service script, which may or may not provide the same features (I dunno, I
don't use it), such as status.

That's useful to know where it is.

Having status would be a debian policy question, I gather.


} What are the "official" debian tools for doing this stuff?  I use wajig
} for starting and stopping services manually.  It's very useful, though
} hardly a "standard" tool.

I uses sysv-rc-conf to manage what starts at what runlevel. For starting
and stopping, though, I really do use the /etc/init.d/<service> scripts.

I find "service" handy since it's less typing :-) Sysv-rc-conf isn't a "standard" tool either in that it isn't installed on all debian systems, any more than service is.

I guess I'm asking for what the party line is for maintenance, rather than optional packages for doing the work.

} Having default startup numbers in the init scripts is handy at times as } well.

I don't know what you mean by this.

RH init scripts include a line in the comments that contains the runlevels it wants to be started in, and the priority numbers to start and stop the script. This integrates with chkconfig, so that when you install an init script, by default it will be enabled at runlevels and priorities that dovetail with the rest of the system. Assuming the init script is well designed of course.

Jerry



Reply to: