# [rc-update] ordre de lancement des scripts [résolu]

## kopp

y a t'il un moyen de donner un ordre au lancement des scripts avec rc-update, parceque la je suis obligé d'attendre que le modem s'initialise et se connecte avant que ca lance gdm... c'est genant...

merci d'avanceLast edited by kopp on Thu Feb 17, 2005 9:12 am; edited 1 time in total

----------

## Enlight

ben dans le script d'initialisation t'as les dependances au début... je pense que ça craint pas trop de virer le modem, mais c'est peut être un peu "crad" comme solution...

----------

## kopp

quel fichier? dans le script de xdm y a pas le modem, pi si je vire le script du  modem du demarrage,  marche tjs, 

seulement je veux le laisser et avoir gdm qui se lance d'abord

----------

## Trevoke

tu peux aller dans /etc/conf.d/rc et mettre "PARALLEL_STARTUP=yes" .. ca fera un boot un peu plus rapide parce qu'il lancera plusieurs choses en meme temps au lieu de le faire de facon sequentielle.

----------

## babykart

oui  cela doit être possible en modifiant le rc-script correspondant...

la partie concernant l'ordre de démarrage sont after() et before()

par ex jette un oeil sur le rc-script de net.eth0...

ou bien peut-être avec depend () { need ... }

sinon je ne sais pas comment on fait précisément...

par contre tu risques d'avoir quelques alarmes en modifiant comme te le dit trevoke...

----------

## Trevoke

Ah bon? Quel genre d'alarmes? J'ai jamais eu de problemes moi ..

----------

## babykart

 *Trevoke wrote:*   

> Ah bon? Quel genre d'alarmes? J'ai jamais eu de problemes moi ..

 

à l'époque ou j'avais fait cette modif', genre il n'arrivait pas à lancer net.eth0 à cause de certaines dépendances je pense...

cela à peut-être été corrigé avec les dernières versions de baselayout mais comme je n'ai pas retesté entre-temps...

----------

## ppierre

Moi aussi j'étais las d'attendre que le modem soit initialisé (speedtouch usb).

Je suis contant que quelqu'un se pose la même question que moi, je vais enfin savoir si ma solution tient la route.

Il y a une petite différence, c'est que j'utilise qingy qui me log automatiquement.

l'idée est que j'ai ajouté 2 runlevel : background et final

```
cp -r /etc/runlevels/{default,final}

cp -r /etc/runlevels/{default,background}
```

J'ai retiré de « default » ce qui n'était pas urgent :

```
rc-update del speedtouch default
```

le runlevel final est le « 4 », background est le « b »

/etc/inittab

```

l0:0:wait:/sbin/rc shutdown 

l1:S1:wait:/sbin/rc single

l2:2:wait:/sbin/rc nonetwork

l3:3:wait:/sbin/rc default

l4:4:wait:/sbin/rc final

l5:5:wait:/sbin/rc default

# TERMINALS

c1:12345:respawn:/sbin/qingy tty1

...

# Used by /etc/init.d/xdm to control DM startup.

# Read the comments in /etc/init.d/xdm for more

# info. Do NOT remove, as this will start nothing

# extra at boot if /etc/init.d/xdm is not added

# to the "default" runlevel.

x:a:once:/etc/X11/startDM.sh

b:b:once:/sbin/rc background
```

Le runlevel « b (background)  » est lancer par « default » sur le même modèle que le runlevel « a » utilisé par xdm (que je n'utilise pas cf: qingy).

/etc/init.d/background

```

#!/sbin/runscript

start() {

        export CONSOLE=/dev/tty6

        /sbin/telinit b &>/dev/null

        eend 0

}
```

```
rc-update add background default 
```

puis le runlevel « b (background) » lance le runlevel « 4 (final) »

/etc/init.d/final

```
#!/sbin/runscript

start() {

        /sbin/telinit 4 &>/dev/null

        eend 0

}
```

```
rc-update add final background
```

Si on veut lancer xdm, on peut sans doute utiliser le runlevel « a » en modifiant etc/X11/startDM.sh pour qu'il lance le runlevel « 4 (final) » ?

```
/sbin/telinit 4 &>/dev/null
```

voilà, je sais pas si j'ai été bien clair, en tout cas cela fonctionne chez moi.

Par contre j'y suis allé au pifometre, alors si quelqu'un sait comment le faire plus proprement...

Une grande question c'est comment re-diriger les messages du runlevel « b » vers un autre terminal, car quand on ne lance pas X, on a une console toute remplie de ces messages. J'ai essayé export CONSOLE=/dev/tty6 sans succès.

----------

## kopp

bah effectivement avec after/ before dans la partie depend ca marche

bon maintenant faut que je regarde le script de xdm et savoir pourquoi ça me marque : setting up gdm... ok et que ça attend que tous les autres truc soit lancée avant d'effectivement lancer xdm

pour le parallel_startup j'ai pas noté de grande difference

----------

## TGL

 *kopp wrote:*   

> bon maintenant faut que je regarde le script de xdm et savoir pourquoi ça me marque : setting up gdm... ok et que ça attend que tous les autres truc soit lancée avant d'effectivement lancer xdm

 

Le cas xdm est vraiment particulier. Le script de startup se contente de dire à init qu'il va falloir passer par le runlevel "a", qui lui lancera le startDM.sh (càd ton [x|k|g]dm). Ce runlevel ne s'exécutera que après que le runlevel normal soit complètement démarré.

Le but de cette bidouille est de ne lancer X que après que les différentes consoles (enfin les agetty) se soient bien posés sur les terminaux virtuels 1 à 6. Si X était démarré avant, il s'allouerait le premier disponible, probablement le vt2 donc.  En fait, pendant longtemps, Xfree ne proposait pas d'option pour forcer le terminal à occuper, d'où la nécessité de cette bidouille (l'alternative étant, comme le faisait Mandrake, de patcher X pour forcer le vt7). 

Si on en crois le bug #70689, ça a enfin dû changer, puisqu'il y a là une solution de proposée qui ne nécessite pas de patcher X, mais juste les scripts de démarrage. Si tu as du temps de bidouille disponible, tu peux essayer ces patchs d'ailleurs (je l'ai pas fait perso faute d'utiliser un xdm, mais à vu de nez ça m'a l'air très censé comme solution).

EDIT: tiens j'm'étais raté sur la balise urlLast edited by TGL on Thu Feb 17, 2005 7:51 pm; edited 1 time in total

----------

## ppierre

J'ai fait un petit essai avec  boutchart

Et voilà,  avant et  après

Les temps qui suivent sont à la louche.

J'ai mis le  patch pour améliorer le démarrage en parallèle des scripts.

Cela m'ai fait gagner 3 4 secondes. Comme je lance la session X très tôt par le biais de qingy, il n'y avait pas grand chose à gagner. Je n'ai pas tester le script qui permet de lancer immédiatement xdm car je ne m'en sert pas.

Ce qui m'a fait gagner le plus de temps c'est de virer xfs qui me prenait ~5 seconde, alors que je ne m'en sert pas.

De la même façon bootgraph m'a permit de voire des petits problèmes :

usb-storage compilé dans le noyau, d'ou vérification à chaque démarrage (2 3 secondes). Je l'ai passé en modules dans l'idée de le charger au besoin.

Même genre de problème avec le module de ma carte tuner (ivtv). Il était long à charger (2 3 secondes) alors je l'ai enlevé des modules chargés au démarrage. Je pense la lancer par le biais d'un service.

Et pour finir éviter à LVM de scanner des périphériques inutiles (2s) :

/etc/lvm/lvm.conf

```
devices { filter=["a|^/dev/hda5|","a|^/dev/hda7|","r|.*|"] }
```

J'ai essayer de mettre le plus de service possible après le lancement du serveur X. Mais cela ne servait pas à grand chose, le temps total pour charger l'environnement graphique reste sensiblement le même. Mais bon pour quelqu'un qui utilise xdm, cela peut faire une différence en lui permettant de se loguer immédiatement.

X n'a finalement pas besoin de beaucoup de service pour se lancer. J'arrive à le faire démarrer au bout de 20 secondes, l'interface graphique (gnome) est finie de charger à 50s. Mais à la fin j'attends toujours que la connexion internet fonctionne (90s).

La morale de l'histoire, il faut que je change de modem  :Rolling Eyes:  !

Voilà à quoi j'ai perdu mon après-midi, j'espère que cela pourra servir à quelqu'un car moi il me faudra plus d'un ans pour avoir récupérer le temps que j'ai passer  :Laughing:  .

----------

## TGL

 *ppierre wrote:*   

> Voilà à quoi j'ai perdu mon après-midi, j'espère que cela pourra servir à quelqu'un car moi il me faudra plus d'un ans pour avoir récupérer le temps que j'ai passer  .

 

Bah l'utilité de grapiller des secondes sur un temps de boot n'est effectivement pas évidente (à part dans l'embarqué, mais c'est une toute autre histoire), mais par contre d'un point de vue purement geek ton étude est très intéressante je trouve. Je connaissais pas bootchart, mais maintenant aucun doute que je vais moi aussi perdre une petite après midi là dessus un de ces quatres  :Wink: 

----------

## kopp

Effectivement, il y avait une ligne dans /etc/init.d/xdm qui faisait attendre tous les tty (en réalité la fin du runlevel, mais en pratique ça revient au même apparemment)

```
start() {

        setup_dm

        ebegin "Setting up ${SERVICE}"

        #save the prefered DM

        save_options "service" "${EXE}"

        #tell init to run /etc/X11/startDM.sh after current

        #runlevel is finished (should *not* be in the "boot"

        #                      runlevel).

        /sbin/telinit a &>/dev/null

        eend 0

}
```

En remplaçant par :

```

start() {

        setup_dm

        ebegin "Setting up ${SERVICE}"

        save_options "service" "${EXE}"

        /etc/X11/startDM.sh

        eend 0

}
```

Ben ça marche mieux  :Smile:   gdm se lance tout de suite

Au passage j'ai fait la petite modif indiquée dans ce post : https://forums.gentoo.org/viewtopic-t-297785.html

C'est mieux de ne pas avoir l'erreur lorsqu'on éteint par gdm

merci TGL

ppierre : espèce de geek va  :Wink: 

EDIT : tiens en fait sur la page du bug donnée par TGL, il y a un autre script proposé, qui diffère du mien.. bon tant pi, à moins que ma méthode soit mauvaise en quelque sorte, mais là, ça marche comme ça!

----------

## ppierre

Visiblement c'est surtout le fichier /usr/X11R6/lib/X11/xdm/Xservers qu'il faut changer :

```
:0 local /usr/X11R6/bin/X vt7
```

pour que le serveur X soit bien sur la console 7

il vaut mieux que tu fasse cette modification, cela ne mange pas de pain.

Sinon ce que tu as fait c'est idem à ce qui est proposé, la seule différence c'est que tu l'a faite en dur alors qu'il en a fait un paramètre de configuration.

Finalement c'est pas compliqué.

Par contre ma solution est totalement tordue !

Je pense que je vais finalement utiliser gdm, mais bon qingy est bien pratique et rapide alors ...  :Sad: 

----------

## sireyessire

@ppierre:

c'est bizarre ton bootchar ne montre qu'un throughtput max de tes disques de 15MB/s, ce qui est pas énorme à priori.

Peut-être peux-tu perdre encore quelques minutes en testant un forcage de dma en passant le paramètre au noyau dans le grub.conf

parce que ça m'étonnerait quand même que tu ais des disques en dma33 avec un athlon-2800+  :Mr. Green: 

ça te fera gagner un peu de temps, va savoir  :Laughing: 

----------

## kopp

Bah, jusque là, ça marche bien et ça lance quand même gdm sur le vt7

M'enfin, j'ai quand même modifié le fichier /usr/.... comme tu me l'as indiqué

D'ailleurs il était en read-only ... bizarre non ? j'ai quand même pu écrire dessus en forçant l'enregistrement, mais alors je comprends plus l'histoire de read-only du coup.. une explication ?

----------

## ppierre

Je sais pas, j'ai un peut l'air bête la ...

J'avais une fois jouer avec hdparm et cela m'avait coûté une instal.

Pour le noyau j'ai :

```
CONFIG_IDE_GENERIC=y

CONFIG_BLK_DEV_IDEPCI=y

CONFIG_IDEPCI_SHARE_IRQ=y

CONFIG_BLK_DEV_IDEDMA_PCI=y

CONFIG_IDEDMA_PCI_AUTO=y

CONFIG_BLK_DEV_SIS5513=y

CONFIG_BLK_DEV_IDEDMA=y

CONFIG_IDEDMA_IVB=y

CONFIG_IDEDMA_AUTO=y
```

Et pour hdparm :

```
root@mini:~ $ hdparm -d 1 -X66 -c 1 -M 254 -W 1 -u 1 -a 4096

 /dev/hda

/dev/hda:

 setting fs readahead to 4096

 setting 32-bit IO_support flag to 1

 setting unmaskirq to 1 (on)

 setting using_dma to 1 (on)

 setting xfermode to 66 (UltraDMA mode2)

 setting drive write-caching to 1 (on)

 IO_support   =  1 (32-bit)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 readahead    = 4096 (on)

 setting acoustic management to 254

 acoustic     =  0 (128=quiet ... 254=fast)

root@mini:~ $ hdparm -tT /dev/hda

/dev/hda:

 Timing cached reads:   1172 MB in  2.00 seconds = 584.92 MB/sec

 Timing buffered disk reads:   58 MB in  3.18 seconds =  18.26 MB/sec

root@mini:~ $ hdparm -I /dev/hda

/dev/hda:

ATA device, with non-removable media

        Model Number:       Maxtor 4A160J0                          

        Serial Number:      A606DFJE            

        Firmware Revision:  RAMB1TU0

Standards:

        Supported: 7 6 5 4 

        Likely used: 7

Capabilities:

        LBA, IORDY(can be disabled)

        Queue depth: 1

        Standby timer values: spec'd by Standard, no device specific minimum

        R/W multiple sector transfer: Max = 16  Current = 16

        Advanced power management level: unknown setting (0x0000)

        Recommended acoustic management value: 192, current value: 254

        DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5 udma6 

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4 

             Cycle time: no flow control=120ns  IORDY flow control=120ns

Commands/features:

        Enabled Supported:

           *    NOP cmd

           *    READ BUFFER cmd

           *    WRITE BUFFER cmd

           *    Host Protected Area feature set

           *    Look-ahead

           *    Write cache

           *    Power Management feature set

                Security Mode feature set

                SMART feature set

           *    FLUSH CACHE EXT command

           *    Mandatory FLUSH CACHE command 

           *    Device Configuration Overlay feature set 

           *    48-bit Address feature set 

           *    Automatic Acoustic Management feature set 

                SET MAX security extension

                Advanced Power Management feature set

           *    DOWNLOAD MICROCODE cmd

           *    SMART self-test 

SMART error logging
```

J'ai fait des essais avec X[66..70] mais rien, pas plus de 20Mo/s

Mais bon j'avais pas acheter ce disque pour les perfs, mais pour stoker de la video.

Si tu as une suggestion ?

Mais bon c'est pas mon thread  :Embarassed:   , ni ma fête  :Laughing:  .

 *Quote:*   

> D'ailleurs il était en read-only ... bizarre non ? j'ai quand même pu écrire dessus en forçant l'enregistrement, mais alors je comprends plus l'histoire de read-only du coup.. une explication ?

 

Je sais pas, avec quel editeur ?

C'est peut-être simplement lui qui à changer les droits (après avoir demandé)

----------

## kopp

euh, avec vim

donc il dit un truc genre : file is read-only, add ! to override

donc :w! j'ai enregistré la modif

----------

## sireyessire

 *ppierre wrote:*   

> Et pour hdparm :
> 
> ```
> root@mini:~ $ hdparm -d 1 -X66 -c 1 -M 254 -W 1 -u 1 -a 4096
> 
> ...

 

et si tu vires le -X66 et que tu le laisses choisir le mode dma, il va pê prendre un mode plus rapide.

tu retestes après avec hdparm -tT

[edit] sinon ce que j'ai dit dans le poste précédent, c'est si tu dois lancer hdparm à chaque démarrage pour avoir le dma qui va bien (rc-update add hdparm default) parce que sinon tu es sans ou avec un mode pourri. En passant l'info lors du boot du noyau, tu es pas obligé d'attendre qu'il ait lancé le service pour avoir du dma, c'est tout.

mais 15Mo ça me parait vraiment pas énorme (c'est quoi comme disque?)

----------

## ppierre

Effectivement cela fonctionne.

Mais bon j'ai jamais u la touche avec vim.

C'est pas faute d'avoir essayé:

```
vimtutor
```

Mais bon il sait faire plein de chose (et au moins chmod u+x)

Par contre j'ai pas trouvé make opt hdparm 

```
root@mini:~ $ hdparm -d 1 -c 1 -M 128 -W 1 -u 1 -a 4096 /dev/hda

/dev/hda:

 setting fs readahead to 4096

 setting 32-bit IO_support flag to 1

 setting unmaskirq to 1 (on)

 setting using_dma to 1 (on)

 setting drive write-caching to 1 (on)

 IO_support   =  1 (32-bit)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 readahead    = 4096 (on)

 setting acoustic management to 128

 acoustic     =  0 (128=quiet ... 254=fast)

root@mini:~ $ hdparm -tT /dev/hda

/dev/hda:

 Timing cached reads:   1124 MB in  2.01 seconds = 560.12 MB/sec

 Timing buffered disk reads:   54 MB in  3.05 seconds =  17.68 MB/sec
```

Sincèrement c'est un vieux disque, laisser le reposer en paix.

Mais bon je dois bien dire que je n'ai jamais rien compris à hdparm.

J'ai bien hdparm dans les runlevels. Et je vérifierais à l'ocassion qu'il garde les paramètres entre chaque boot.

J'ai plusieurs disques comme celui-la : des matrox 160Go, les premiers sont des 5400tr/mn, celui-çi et un des premiers 7200tr/mn. Mais te casse pas la tête, le dernier fait 30Mo/s. Alors à mon avis c'est le disque.

Pour Noël : Je commande deux raptor pour plus me faire bâcher  :Laughing: 

----------

## TGL

 *ppierre wrote:*   

> Et je vérifierais à l'ocassion qu'il garde les paramètres entre chaque boot.

 

À ma connaissance, il n'y a pas de sauvegarde automatique des paramètres. Par contre, tu peux forcer ce que tu veux à chaque boot en configurant /etc/conf.d/hdparm, avec des lignes du genre : 

```
hda_args="-d1 -c1 -u1"
```

----------

## ppierre

J'ai

/etc/conf.d/hdparm

```
cdrom0_args="-d 1 -X66 -c 1 -u 1 -a 4096"

disc0_args="-d 1 -X66 -c 1 -M 254 -W 1 -u 1 -a 4096 -k 1"

disc1_args="-d 1 -X66 -c 1 -M 254 -W 1 -u 1 -a 4096 -k 1"
```

Peut-être k mais je pas bien sur de bien comprendre si c'est entre chaque démarrage?

```
$ hdparm

...

-k   get/set keep_settings_over_reset flag (0/1)

...
```

Mais il ne faut pas chercher c'est une config de récup avec un petit boiter et un nouveau processeur. Avant je vivais heureu avec mon 1Ghz. Alors du momment que cela ne plante pas...

----------

## TGL

Oh, bah je connaissais pas ce "-k". Aucune idée de comment il se comporte donc. Mais enfin bon, comme tu dis, tant que ton système est fiable, c'est le principal...

----------

## sireyessire

oki donc les 15 Mo/s en pointe ne sont pas si surprenant, alors. Ok, mais ça vallait le coup de vérifier car si le dma ne tournait pas avant le démarrage de l'init script, c'est moins rapide...

----------

