Re: Universal method to start a script at boot

Re: Universal method to start a script at boot

[Brad Tilley]

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

Re: Universal method to start a script at boot

[Michael Clark]

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

Re: Universal method to start a script at boot

[Denis Vlasenko]

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

Re: Universal method to start a script at boot

[DervishD]

    Hi Denis :)

 * Denis Vlasenko <vda@ilport.com.ua> 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...

Re: Universal method to start a script at boot

[Denis Vlasenko]

On Monday 12 September 2005 14:07, DervishD wrote:
>     Hi Denis :)
> 
>  * Denis Vlasenko <vda@ilport.com.ua> 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

Re: Universal method to start a script at boot

[DervishD]

    Hi Denis :)

 * Denis Vlasenko <vda@ilport.com.ua> 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...

Re: Universal method to start a script at boot

[linux-os (Dick Johnson)]

On Mon, 12 Sep 2005, DervishD wrote:

>    Hi Denis :)
>
> * Denis Vlasenko <vda@ilport.com.ua> 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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Universal method to start a script at boot

[Michael Clark]

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

Re: Universal method to start a script at boot

[Brad Tilley]

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.