This is off-topic and I apologize. However, I think some here could answer
this.
> Is there a standard way to start a script or program at boot that will work
> on any Linux kernel/distro no matter which init system is being used or how it
> has been configured? Probably not, but I thought someone here could possibly
> answer this.
I'm off-list so if you have an answer, please cc me on replies.
Thanks,
Brad
Brad Tilley wrote:
>This is off-topic and I apologize. However, I think some here could answer
>this.
>
>
>
>>Is there a standard way to start a script or program at boot that will work
>>on any Linux kernel/distro no matter which init system is being used or how it
>>has been configured? Probably not, but I thought someone here could possibly
>>answer this.
>>
>>
You could use the LSB conforming method of writing and installing
an init script:
http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html
http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html
Most of the main distros support this (Fedora, RHEL, SuSE,
Mandriva, Debian, ...). Not to say all of them ship with the
LSB support packages installed by default. Some do some don't.
On Debian I need to do an "apt-get install lsb".
~mc
On Monday 12 September 2005 07:17, Michael Clark wrote:
> >>Is there a standard way to start a script or program at boot that will work
> >>on any Linux kernel/distro no matter which init system is being used or how it
> >>has been configured? Probably not, but I thought someone here could possibly
> >>answer this.
>
> You could use the LSB conforming method of writing and installing
> an init script:
>
> http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
> http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html
> http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
> http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html
Awful. This codifies ages-old Unix traditional SysV-like init
and its derivatives, which should be get rid of instead.
daemontools are absolutely wonderful way of controlling daemons.
This is how sane system may look instead:
# ps -AH e
PID TTY STAT TIME COMMAND
1 ? S 0:01 /bin/sh /init
539 ? S< 0:00 udevd UDEV_LOG=debug
593 ? S 0:00 rpc.portmap
702 ? S 0:00 svscan /var/service PATH=/bin:/usr/bin
720 ? S 0:00 supervise fw PATH=/bin:/usr/bin
721 ? S 0:00 supervise gpm PATH=/bin:/usr/bin
1597 ? S 0:00 gpm -D -2 -m /dev/psaux -t ps2
722 ? S 0:00 supervise nfs PATH=/bin:/usr/bin
743 ? S 0:00 /bin/sh ./run PATH=/bin:/usr/bin
1097 ? S 0:00 sleep 32000
723 ? S 0:00 supervise ntp PATH=/bin:/usr/bin
736 ? SL 0:00 ntpd -D 0 -c conf -f drift -s stat -l /proc/self/fd/2 -p /dev/null -k /dev/null -g -d -n
724 ? S 0:00 supervise log PATH=/bin:/usr/bin
737 ? S 0:00 multilog t /var/log/service/ntp
725 ? S 0:00 supervise smb PATH=/bin:/usr/bin
726 ? S 0:00 supervise log PATH=/bin:/usr/bin
730 ? S 0:00 multilog t /var/log/service/smb
727 ? S 0:00 supervise top PATH=/bin:/usr/bin
760 ? S 1:00 top c s TERM=linux
728 ? S 0:00 supervise dhcp PATH=/bin:/usr/bin
729 ? S 0:00 supervise log PATH=/bin:/usr/bin
755 ? S 0:00 multilog t /var/log/service/dhcp
744 ? S 0:00 supervise klog PATH=/bin:/usr/bin
784 ? S 0:00 socklog ucspi
745 ? S 0:00 supervise log PATH=/bin:/usr/bin
780 ? S 0:00 svlogd -tt /var/log/service/klog
746 ? S 0:00 supervise once PATH=/bin:/usr/bin
747 ? S 0:00 supervise sshd PATH=/bin:/usr/bin
748 ? S 0:00 /usr/bin/sshd -D -e -p22 -u0
775 ? S 0:00 supervise r_zebra PATH=/bin:/usr/bin
776 ? S 0:00 supervise log PATH=/bin:/usr/bin
797 ? S 0:00 multilog t /var/log/service/r_zebra
777 ? S 0:00 supervise httpd PATH=/bin:/usr/bin
792 ? S 0:00 tcpserver -v -R -H -l 0 -c 40 0.0.0.0 www setuidgid root httpd -X -f /.local/var/service/httpd/httpd.conf
778 ? S 0:00 supervise log PATH=/bin:/usr/bin
788 ? S 0:00 multilog t /var/log/service/httpd
786 ? S 0:00 supervise pgsql PATH=/bin:/usr/bin
787 ? S 0:00 supervise log PATH=/bin:/usr/bin
832 ? S 0:00 multilog t /var/log/service/pgsql
815 ? S 0:00 supervise smb_s PATH=/bin:/usr/bin
816 ? S 0:00 supervise log PATH=/bin:/usr/bin
840 ? S 0:00 multilog t /var/log/service/smb_s
817 ? S 0:00 supervise nfs_mountd PATH=/bin:/usr/bin
846 ? S 0:00 rpc.mountd --foreground --debug all
827 ? S 0:00 supervise log PATH=/bin:/usr/bin
857 ? S 0:00 multilog t /var/log/service/nfs_mountd
828 ? S 0:00 supervise getty_ttyM0 PATH=/bin:/usr/bin
829 ? S 0:00 supervise getty_ttyS0 PATH=/bin:/usr/bin
830 ? S 0:00 supervise nmeter PATH=/bin:/usr/bin
1011 ? S 0:00 nmeter t c i x p b nif
881 ? S 0:00 supervise ovpn-1 PATH=/bin:/usr/bin
882 ? S 0:00 supervise log PATH=/bin:/usr/bin
954 ? S 0:00 multilog /var/log/service/ovpn-1
884 ? S 0:00 supervise r_ospf PATH=/bin:/usr/bin
885 ? S 0:00 supervise log PATH=/bin:/usr/bin
886 ? S 0:00 multilog /var/log/service/r_ospf
889 ? S 0:00 supervise getty_tty1 PATH=/bin:/usr/bin
890 ? S 0:00 supervise getty_tty2 PATH=/bin:/usr/bin
970 ? S 0:00 login -- vda
1676 tty2 S 0:00 -bash HOME=/home/vda PATH=/sbin:/bin:/usr/sbin:/usr/bin SHELL=/bin/bash TERM=linux MAIL=/var/mail/vda LOGNAME=vda
891 ? S 0:00 supervise getty_tty3 PATH=/bin:/usr/bin
975 tty3 S 0:00 agetty 38400 /dev/tty3 linux TERM=linux
892 ? S 0:00 supervise getty_tty4 PATH=/bin:/usr/bin
969 tty4 S 0:00 agetty 38400 /dev/tty4 linux TERM=linux
893 ? S 0:00 supervise getty_tty5 PATH=/bin:/usr/bin
964 tty5 S 0:00 agetty 38400 /dev/tty5 linux TERM=linux
894 ? S 0:00 supervise getty_tty6 PATH=/bin:/usr/bin
960 tty6 S 0:00 agetty 38400 /dev/tty6 linux TERM=linux
895 ? S 0:00 supervise getty_tty7 PATH=/bin:/usr/bin
912 tty7 S 0:00 agetty 38400 /dev/tty7 linux TERM=linux
896 ? S 0:00 supervise getty_tty8 PATH=/bin:/usr/bin
915 tty8 S 0:00 agetty 38400 /dev/tty8 linux TERM=linux
897 ? S 0:00 supervise syslog PATH=/bin:/usr/bin
898 ? S 0:00 socklog unix /dev/log PATH=/bin:/usr/bin PWD=/.local/var/service/syslog SHLVL=0 GID=50 UID=58
899 ? S 0:00 supervise log PATH=/bin:/usr/bin
903 ? S 0:00 svlogd /var/log/service/syslog
900 ? S 0:00 supervise nfs_statd PATH=/bin:/usr/bin
934 ? S 0:00 rpc.statd -F -d
910 ? S 0:00 supervise log PATH=/bin:/usr/bin
911 ? S 0:00 multilog t /var/log/service/nfs_statd
924 ? S 0:00 supervise automount PATH=/bin:/usr/bin
951 ? S 0:00 automount -f -s -v -d --timeout 15 /.local/mnt/auto program /root/bin/mapper.sh
925 ? S 0:00 supervise log PATH=/bin:/usr/bin
926 ? S 0:02 multilog t n5 /var/log/service/automount
928 ? S 0:00 supervise watcher PATH=/bin:/usr/bin
929 ? S 0:00 supervise udhcpd_eth0 PATH=/bin:/usr/bin
719 ? S 0:00 sleep 32000
And /init is:
#!/bin/sh
# Clean up env
unset HOSTNAME
unset devfs
unset MACHTYPE
unset SHLVL
unset SHELL
unset HOSTTYPE
unset OSTYPE
unset HOME
unset TERM
PATH=/bin:/usr/bin
exec >/dev/console
exec 2>&1
exec </dev/null
env - PATH="$PATH" /etc/some_startup_script_which_also_starts_svscan
# Close all descriptors
exec >&-
exec 2>&-
exec <&-
while true; do env - sleep 32000; done
--
vda
Hi Denis :)
* Denis Vlasenko <[email protected]> dixit:
> Awful. This codifies ages-old Unix traditional SysV-like init
> and its derivatives, which should be get rid of instead.
I'm with you in this, in fact I use my own init system, but...
> daemontools are absolutely wonderful way of controlling daemons.
How the heck you make sure that svscan starts the services in the
correct order? Does it run the services in /services in any
particular order or just in the order resulting for a simple
globbing? How you make sure the services are shut down in any
particular order?
All this seems like requiring scripts to do the job (that is,
ensuring a particular order of startup/shutdown), while sysvinit
gets this info from filenames. Obviously, dictating the order using a
script is far more flexible than using filenames but it's not as
simple, and that cannot be seen in the comparisons D.J.B. does in the
homepage of daemontools (which, BTW, is the only source of
documentation, and a very poor one). LSB, on the other hand, is
better structured and although I don't like sysvinit at all, the
system is better documented. And I hate runlevels...
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...
On Monday 12 September 2005 14:07, DervishD wrote:
> Hi Denis :)
>
> * Denis Vlasenko <[email protected]> dixit:
> > Awful. This codifies ages-old Unix traditional SysV-like init
> > and its derivatives, which should be get rid of instead.
>
> I'm with you in this, in fact I use my own init system, but...
>
> > daemontools are absolutely wonderful way of controlling daemons.
>
> How the heck you make sure that svscan starts the services in the
> correct order?
Simple. Usually I do not, because many of them do not
depend on each other. In cases where I must, I code it
in the script.
This is how do I wait for automount to start before
I mkswap/swapon on a windows nt swapfile:
echo -n "* Setting up swap"
i=9; while test "$i" -gt 0; do
if test -d /mnt/auto/vfat.hda1; then
echo
mkswap /mnt/auto/vfat.hda1/PAGEFILE.SYS
swapon /mnt/auto/vfat.hda1/PAGEFILE.SYS
exit
fi
echo -n "."
sleep 1
let i-=1; done
echo
Probably a small tool can make it look less ugly
(say, 'waitfor <seconds> <cmd> [<param>]'):
if waitfor 10 test -d /mnt/auto/vfat.hda1; then ...; fi
> > Does it run the services in /services in any
> particular order or just in the order resulting for a simple
> globbing? How you make sure the services are shut down in any
> particular order?
>
> All this seems like requiring scripts to do the job (that is,
> ensuring a particular order of startup/shutdown), while sysvinit
> gets this info from filenames. Obviously, dictating the order using a
> script is far more flexible than using filenames but it's not as
> simple, and that cannot be seen in the comparisons D.J.B. does in the
> homepage of daemontools (which, BTW, is the only source of
> documentation, and a very poor one). LSB, on the other hand, is
djb is crazy genius, what did you expect ;)
There is GPLed replacement of daemontools at http://smarden.org/runit/
> better structured and although I don't like sysvinit at all, the
> system is better documented. And I hate runlevels...
me too.
--
vda
Denis Vlasenko wrote:
>On Monday 12 September 2005 07:17, Michael Clark wrote:
>
>
>>>>Is there a standard way to start a script or program at boot that will work
>>>>on any Linux kernel/distro no matter which init system is being used or how it
>>>>has been configured? Probably not, but I thought someone here could possibly
>>>>answer this.
>>>>
>>>>
>>You could use the LSB conforming method of writing and installing
>>an init script:
>>
>>http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
>>http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html
>>http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
>>http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html
>>
>>
>
>Awful. This codifies ages-old Unix traditional SysV-like init
>and its derivatives, which should be get rid of instead.
>
>
>
Actually if you look closer it is a bit smarter than sysvinit and
includes latent functionality that the distros will eventually pick up
on to increase boot speed and allow parallel starting of services (it
codifies boot dependencies with provides and requires - not just boot
order like svsvinit).
http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
For example an extract from /etc/init.d/vmware
# Basic support for the Linux Standard Base Specification 1.3
# Used by insserv and other LSB compliant tools.
### BEGIN INIT INFO
# Provides: VMware
# Required-Start: $network $syslog
# Required-Stop:
# Default-Start: 2 3 5
# Default-Stop: 0 6
# Short-Description: Manages the services needed to run VMware software
# Description: Manages the services needed to run VMware software
### END INIT INFO
And whether you think it is awful or not - it is the closest thing we
have to universal in Linux land (which is what the original poster was
asking) ie. all of the major distros are aiming for LSB conformance.
~mc
On Mon, 12 Sep 2005, DervishD wrote:
> Hi Denis :)
>
> * Denis Vlasenko <[email protected]> dixit:
>> Awful. This codifies ages-old Unix traditional SysV-like init
>> and its derivatives, which should be get rid of instead.
>
> I'm with you in this, in fact I use my own init system, but...
>
>> daemontools are absolutely wonderful way of controlling daemons.
>
> How the heck you make sure that svscan starts the services in the
> correct order? Does it run the services in /services in any
> particular order or just in the order resulting for a simple
> globbing? How you make sure the services are shut down in any
> particular order?
>
> All this seems like requiring scripts to do the job (that is,
> ensuring a particular order of startup/shutdown), while sysvinit
> gets this info from filenames. Obviously, dictating the order using a
> script is far more flexible than using filenames but it's not as
> simple, and that cannot be seen in the comparisons D.J.B. does in the
> homepage of daemontools (which, BTW, is the only source of
> documentation, and a very poor one). LSB, on the other hand, is
> better structured and although I don't like sysvinit at all, the
> system is better documented. And I hate runlevels...
>
> Ra?l N??ez de Arenas Coronado
The embedded systems we use have a "home-made" `init` that
does everything in the coded order. This means that there is
no shell so the system can't be hacked in the usual ways.
Also, some technician in "final test" can't forget to do
something that results in a disaster once a system is in
the field. If the system runs, it's running in its intended
manner.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.53 BogoMips).
Warning : 98.36% of all statistics are fiction.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Hi Denis :)
* Denis Vlasenko <[email protected]> dixit:
> > How the heck you make sure that svscan starts the services in the
> > correct order?
> Simple. Usually I do not, because many of them do not
> depend on each other. In cases where I must, I code it
> in the script.
OK, that's what I supposed. For small systems I usually prefer
the sysvinit approach for ordering, anyway.
> > All this seems like requiring scripts to do the job (that is,
> > ensuring a particular order of startup/shutdown), while sysvinit
> > gets this info from filenames. Obviously, dictating the order using a
> > script is far more flexible than using filenames but it's not as
> > simple, and that cannot be seen in the comparisons D.J.B. does in the
> > homepage of daemontools (which, BTW, is the only source of
> > documentation, and a very poor one). LSB, on the other hand, is
> djb is crazy genius, what did you expect ;)
Yes ;))))
> There is GPLed replacement of daemontools at http://smarden.org/runit/
I know it, too, but I thought it was *based* on daemontools. I'll
take a look at it. Anyway, my init clone is compatible (more or less)
with both init.d and daemontools.
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...
On Mon, 2005-09-12 at 12:17 +0800, Michael Clark wrote:
> Brad Tilley wrote:
>
> >This is off-topic and I apologize. However, I think some here could answer
> >this.
> >
> >
> >
> >>Is there a standard way to start a script or program at boot that will work
> >>on any Linux kernel/distro no matter which init system is being used or how it
> >>has been configured? Probably not, but I thought someone here could possibly
> >>answer this.
> >>
> >>
>
> You could use the LSB conforming method of writing and installing
> an init script:
>
> http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
> http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html
> http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
> http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html
>
> Most of the main distros support this (Fedora, RHEL, SuSE,
> Mandriva, Debian, ...). Not to say all of them ship with the
> LSB support packages installed by default. Some do some don't.
>
> On Debian I need to do an "apt-get install lsb".
>
> ~mc
>
Thank you. I think this is the best approach for me.