Re: systemd et fichiers dans /etc/init.d/

[BERTRAND Joël]

steve a écrit :
> Le 30-01-2018, à 18:21:55 +0100, BERTRAND Joël a écrit :
> 
>> steve a écrit :
>>> Le 30-01-2018, à 15:08:21 +0100, BERTRAND Joël a écrit :
>>>
>>>
>>>>>> Ce qui permet d'ailleurs des effets de bord assez rigolos entre deux
>>>>>> versions de la chose.
>>>>>
>>>>> Du genre ? As-tu des exemples concrets ?
>>>>
>>>> Des incohérences sur la gestion du réseau par exemple sur un
>>>> serveur
>>>> qui a deux taps, deux tuns, une interface bounding et cinq ethernet. En
>>>> fonction des versions de la bouse, ça démarre automatiquement ou non
>>>> (c'est le VPN qui merdoie à cause de son interaction avec iptables).
>>>
>>> Pourquoi avoir migré sur une configuration si complexe alors qu'il est
>>> possible de garder l'ancien système ?
>>
>> Parce qu'il fallait bien que je me fasse une idée.
> 
> Tu aurais pu te la faire sur un système un peu moins complexe, non ?

Bah non... Sur mon serveur de test avec une configuration simple, ça
fonctionnait. Ce n'est _que_ parce que la configuration était complexe
que systemd s'est baugé lamentablement comme la bouse qu'il est.

>> Depuis, cette idée est faite, systemd est une calamité qui fonctionne
>> dans 98% des cas. SysV fonctionne quant à lui dans 100% des cas. Il faut
>> juste ne pas être dans les 2%.
> 
> Et tu peux vivre avec ce risque sur des machines de production ? Tes
> nuits doivent être mouvementées :)

Merci, mes nuits sont généralement calmes.

>>>>>> La seule chose qui peut à la rigueur être faite, c'est de
>>>>>> virer de
>>>>>> /etc/init.d ce qui est explicitement transcrit dans /lib/systemd
>>>>>> pour le
>>>>>> fonctionnement de l'usine à gaz avec des fuites.
>>>>>
>>>>> Mais ces fichiers seront réinstallés à la prochaine maj. Donc assez
>>>>> inutile.
>>>>>
>>>>>
>>>>>> PS: oui, je pense que ça s'est vu que je n'aime pas cette bouse... Et
>>>>>> plus je rentre dedans, pire c'est.
>>>>>
>>>>> Rien à lui reprocher pour le moment pour un usage domestique.
>>>> Il n'y a pas que l'usage domestique.
>>>
>>> Je sais, c'est pour cela que j'ai précisé.
>>>
>>>> Depuis qu'on a systemd, j'en suis à ne plus redémarrer (sauf lorsque
>>>> tout est déjà perdu) des serveurs à distance.
>>>
>>> Toujours chauds ce genre de manips, quelque soit le système.
>>
>> Euh, non. Ça fait plus de 20 ans que j'ai des serveurs un peu
>> partout,
>> je n'ai peur de les redémarrer que lorsqu'ils utilisent systemd, surtout
>> après une mise à jour.
> 
> Je me rappelle avoir dû me déplacer à l'époque pour des serveurs qui ne
> répondaient plus après un redémarrage.

Moi aussi. Mais là, je ne parle même pas du démarrage, mais de l'arrêt.
Par ailleurs, le système de boot de Linux est une vaste pantalonnade. Le
coup du initrd ou du ramfs, c'est vraiment grandiose, surtout depuis que
/etc/modules n'est pas exporté dans le ramfs. Un bricolage ! Il n'y a
aucune raison valable pour ne pas utiliser un système à la BSD.

>>>> Il y en a même qui ne s'arrêtent pas !
>>>
>>>
>>> M'est aussi arrivé avec l'ancien et obsolète système… Heureusement
>>> qu'il y avait une prise physique  ;)
>>
>> Ça, j'aimerais bien savoir comment. Parce que SysV essaie d'arrêter
>> proprement les daemons. Il passe après un SIGTERM puis en dernier
>> ressort un SIGKILL. Si la machine ne s'arrêtait pas, ce n'était
>> certainement pas la faute d'init.
> 
> Peut-être, peut-être pas…

Pour info, SIGKILL ne peut pas être récupéré par un programme. Donc
soit init est plant (jamais vu pour le SysV), soit le système est en
vrac (et ce n'est pas la faute d'init).

JKB

Re: systemd et fichiers dans /etc/init.d/

[steve]

Le 30-01-2018, à 18:21:55 +0100, BERTRAND Joël a écrit :


steve a écrit :

Le 30-01-2018, à 15:08:21 +0100, BERTRAND Joël a écrit :



Ce qui permet d'ailleurs des effets de bord assez rigolos entre deux
versions de la chose.


Du genre ? As-tu des exemples concrets ?


Des incohérences sur la gestion du réseau par exemple sur un serveur
qui a deux taps, deux tuns, une interface bounding et cinq ethernet. En
fonction des versions de la bouse, ça démarre automatiquement ou non
(c'est le VPN qui merdoie à cause de son interaction avec iptables).


Pourquoi avoir migré sur une configuration si complexe alors qu'il est
possible de garder l'ancien système ?


Parce qu'il fallait bien que je me fasse une idée.


Tu aurais pu te la faire sur un système un peu moins complexe, non ?



Depuis, cette idée est faite, systemd est une calamité qui fonctionne
dans 98% des cas. SysV fonctionne quant à lui dans 100% des cas. Il faut
juste ne pas être dans les 2%.


Et tu peux vivre avec ce risque sur des machines de production ? Tes
nuits doivent être mouvementées :)


La seule chose qui peut à la rigueur être faite, c'est de virer de
/etc/init.d ce qui est explicitement transcrit dans /lib/systemd
pour le
fonctionnement de l'usine à gaz avec des fuites.


Mais ces fichiers seront réinstallés à la prochaine maj. Donc assez
inutile.



PS: oui, je pense que ça s'est vu que je n'aime pas cette bouse... Et
plus je rentre dedans, pire c'est.


Rien à lui reprocher pour le moment pour un usage domestique.

Il n'y a pas que l'usage domestique.


Je sais, c'est pour cela que j'ai précisé.


Depuis qu'on a systemd, j'en suis à ne plus redémarrer (sauf lorsque
tout est déjà perdu) des serveurs à distance.


Toujours chauds ce genre de manips, quelque soit le système.


Euh, non. Ça fait plus de 20 ans que j'ai des serveurs un peu partout,
je n'ai peur de les redémarrer que lorsqu'ils utilisent systemd, surtout
après une mise à jour.


Je me rappelle avoir dû me déplacer à l'époque pour des serveurs qui ne
répondaient plus après un redémarrage.


Il y en a même qui ne s'arrêtent pas !



M'est aussi arrivé avec l'ancien et obsolète système… Heureusement
qu'il y avait une prise physique  ;)


Ça, j'aimerais bien savoir comment. Parce que SysV essaie d'arrêter
proprement les daemons. Il passe après un SIGTERM puis en dernier
ressort un SIGKILL. Si la machine ne s'arrêtait pas, ce n'était
certainement pas la faute d'init.


Peut-être, peut-être pas…

Steve

Re: systemd et fichiers dans /etc/init.d/

[Charles Plessy]

> Le 30-01-2018, à 14:15:30 +0100, Ph. Gras a écrit :
> 
> > Qu'en sera-t-il de la commande service machin (start | restant | stop | 
> > reload ) ?

Le Tue, Jan 30, 2018 at 02:37:08PM +0100, steve a écrit :
> 
> C'est remplacé par
> 
> systemctl (start|restart|stop|reload) le_nom_du_service

D'ailleurs, un coup d'oeil rapide à /usr/sbin/service montre qu'il
appelle systemctl le cas échéant.

Bonne journée,

-- 
Charles

Re: systemd et fichiers dans /etc/init.d/

[BERTRAND Joël]

steve a écrit :
> Le 30-01-2018, à 15:08:21 +0100, BERTRAND Joël a écrit :
> 
> 
>>>> Ce qui permet d'ailleurs des effets de bord assez rigolos entre deux
>>>> versions de la chose.
>>>
>>> Du genre ? As-tu des exemples concrets ?
>>
>> Des incohérences sur la gestion du réseau par exemple sur un serveur
>> qui a deux taps, deux tuns, une interface bounding et cinq ethernet. En
>> fonction des versions de la bouse, ça démarre automatiquement ou non
>> (c'est le VPN qui merdoie à cause de son interaction avec iptables).
> 
> Pourquoi avoir migré sur une configuration si complexe alors qu'il est
> possible de garder l'ancien système ?

Parce qu'il fallait bien que je me fasse une idée.

Depuis, cette idée est faite, systemd est une calamité qui fonctionne
dans 98% des cas. SysV fonctionne quant à lui dans 100% des cas. Il faut
juste ne pas être dans les 2%.

>>>> La seule chose qui peut à la rigueur être faite, c'est de virer de
>>>> /etc/init.d ce qui est explicitement transcrit dans /lib/systemd
>>>> pour le
>>>> fonctionnement de l'usine à gaz avec des fuites.
>>>
>>> Mais ces fichiers seront réinstallés à la prochaine maj. Donc assez
>>> inutile.
>>>
>>>
>>>> PS: oui, je pense que ça s'est vu que je n'aime pas cette bouse... Et
>>>> plus je rentre dedans, pire c'est.
>>>
>>> Rien à lui reprocher pour le moment pour un usage domestique.
>> Il n'y a pas que l'usage domestique.
> 
> Je sais, c'est pour cela que j'ai précisé.
> 
>> Depuis qu'on a systemd, j'en suis à ne plus redémarrer (sauf lorsque
>> tout est déjà perdu) des serveurs à distance.
> 
> Toujours chauds ce genre de manips, quelque soit le système.

Euh, non. Ça fait plus de 20 ans que j'ai des serveurs un peu partout,
je n'ai peur de les redémarrer que lorsqu'ils utilisent systemd, surtout
après une mise à jour.

>> Il y en a même qui ne s'arrêtent pas !
> 
> 
> M'est aussi arrivé avec l'ancien et obsolète système… Heureusement
> qu'il y avait une prise physique  ;)

Ça, j'aimerais bien savoir comment. Parce que SysV essaie d'arrêter
proprement les daemons. Il passe après un SIGTERM puis en dernier
ressort un SIGKILL. Si la machine ne s'arrêtait pas, ce n'était
certainement pas la faute d'init.

JKB

Re: systemd et fichiers dans /etc/init.d/

[steve]

Le 30-01-2018, à 15:07:03 +0100, G2PC a écrit :




Salut Steve,

la commande suivante t'indiquera quels fichiers ne sont pas installés
par un paquet.

dpkg -S /etc/init.d/* | grep "no path"

Les autres peuvent rester: le responsable du paquet s'occupe (à son
rythme) de la migration vers systemd et conserve (autant que possible)
les scripts sysvinit pour les installations utilisant ce système.


Bonjour, j'ai regardé votre sujet en diagonale. J'ai lancé la commande,
mais, j'obtiens ce retour :

dpkg -S /etc/init.d/* | grep "no path"
dpkg-query: aucun chemin ne correspond à /etc/init.d/keyboard-setup.dpkg-bak
zsh: exit 1 dpkg -S /etc/init.d/* | grep "no path"

Noter que je ne suis pas sous Debian mais Mint.


Mint utilise une base Ubuntu si je ne m'abuse. Et si mes souvenirs sont
bons, ils ont abandonné sysvinit depuis bien longtemps, donc il y a fort
à parier que /etc/init.d/ est vide.


Sous GNU/Linux Debian Stretch, et, mon serveur minimaliste, la commande
ne me retourne rien, sans message d'erreur.


Alors tout est parfait  ;)

Steve


PS: toujours que 2PC ?

Re: systemd et fichiers dans /etc/init.d/

[steve]

Le 30-01-2018, à 15:08:21 +0100, BERTRAND Joël a écrit :



Ce qui permet d'ailleurs des effets de bord assez rigolos entre deux
versions de la chose.


Du genre ? As-tu des exemples concrets ?


Des incohérences sur la gestion du réseau par exemple sur un serveur
qui a deux taps, deux tuns, une interface bounding et cinq ethernet. En
fonction des versions de la bouse, ça démarre automatiquement ou non
(c'est le VPN qui merdoie à cause de son interaction avec iptables).


Pourquoi avoir migré sur une configuration si complexe alors qu'il est
possible de garder l'ancien système ?


La seule chose qui peut à la rigueur être faite, c'est de virer de
/etc/init.d ce qui est explicitement transcrit dans /lib/systemd pour le
fonctionnement de l'usine à gaz avec des fuites.


Mais ces fichiers seront réinstallés à la prochaine maj. Donc assez
inutile.



PS: oui, je pense que ça s'est vu que je n'aime pas cette bouse... Et
plus je rentre dedans, pire c'est.


Rien à lui reprocher pour le moment pour un usage domestique.

Il n'y a pas que l'usage domestique.


Je sais, c'est pour cela que j'ai précisé.


Depuis qu'on a systemd, j'en suis à ne plus redémarrer (sauf lorsque
tout est déjà perdu) des serveurs à distance.


Toujours chauds ce genre de manips, quelque soit le système.



Il y en a même qui ne s'arrêtent pas !



M'est aussi arrivé avec l'ancien et obsolète système… Heureusement
qu'il y avait une prise physique  ;)

Re: systemd et fichiers dans /etc/init.d/

[G2PC]

> Salut Steve,
>
> la commande suivante t'indiquera quels fichiers ne sont pas installés
> par un paquet.
>
> dpkg -S /etc/init.d/* | grep "no path"
>
> Les autres peuvent rester: le responsable du paquet s'occupe (à son
> rythme) de la migration vers systemd et conserve (autant que possible)
> les scripts sysvinit pour les installations utilisant ce système.

Bonjour, j'ai regardé votre sujet en diagonale. J'ai lancé la commande,
mais, j'obtiens ce retour :

dpkg -S /etc/init.d/* | grep "no path"
dpkg-query: aucun chemin ne correspond à /etc/init.d/keyboard-setup.dpkg-bak
zsh: exit 1 dpkg -S /etc/init.d/* | grep "no path"

Noter que je ne suis pas sous Debian mais Mint.

Sous GNU/Linux Debian Stretch, et, mon serveur minimaliste, la commande
ne me retourne rien, sans message d'erreur.

Re: systemd et fichiers dans /etc/init.d/

[BERTRAND Joël]

steve a écrit :
> Le 29-01-2018, à 19:12:17 +0100, BERTRAND Joël a écrit :
> 
>> steve a écrit :
>>>
>>> Salut,
>>
>> 'soir
>>
>>>
>>> M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
>>> principale), je me demandais si les fichiers placés dans /etc/init.d/
>>> sont encore utilisés ou s'ils ne sont là que pour une éventuelle
>>> compatibilité avec les systèmes utilisant SysVInit plutôt que systemd.
>>>
>>> Dans la négative, y a-t-il un moyen propre de nettoyer le système de ces
>>> fichiers inutiles ? Je veux dire, sans 'rm -rf /etc/init.d', car ces
>>> fichiers sont présents dans les paquets Debian. Je sais qu'ils prennent
>>> une place plus que négligeable, mais ce serait quand même plus élégant
>>> de ne plus avoir de restes de l'ancien système.
>>
>> Surtout pas, malheureux ! Le blob systemd va rechercher les modules
>> dans /lib/systemd mais s'il ne trouve rien, il convertit à la volée ce
>> qui est dans /etc/init.d dans son format pour tenter de faire
>> difficillement ce que l'ancien init SysV faisait très simplement. Ce qui
>> permet d'ailleurs des effets de bord assez rigolos entre deux versions
>> de la chose.
> 
> Du genre ? As-tu des exemples concrets ?

Des incohérences sur la gestion du réseau par exemple sur un serveur
qui a deux taps, deux tuns, une interface bounding et cinq ethernet. En
fonction des versions de la bouse, ça démarre automatiquement ou non
(c'est le VPN qui merdoie à cause de son interaction avec iptables).

>> La seule chose qui peut à la rigueur être faite, c'est de virer de
>> /etc/init.d ce qui est explicitement transcrit dans /lib/systemd pour le
>> fonctionnement de l'usine à gaz avec des fuites.
> 
> Mais ces fichiers seront réinstallés à la prochaine maj. Donc assez
> inutile.
> 
> 
>> PS: oui, je pense que ça s'est vu que je n'aime pas cette bouse... Et
>> plus je rentre dedans, pire c'est.
> 
> Rien à lui reprocher pour le moment pour un usage domestique.
Il n'y a pas que l'usage domestique. Depuis qu'on a systemd, j'en suis
à ne plus redémarrer (sauf lorsque tout est déjà perdu) des serveurs à
distance. Il y en a même qui ne s'arrêtent pas !

JKB

Re: systemd et fichiers dans /etc/init.d/

[steve]

Le 30-01-2018, à 14:15:30 +0100, Ph. Gras a écrit :


Je ne sais pas si ça sert encore.  Mais il semble être trop tôt pour l'enlever:


Ainsi, le répertoire init.d et tout ce qui s'y trouve devraient disparaître à 
terme ?


Si le système tourne à 100% avec SystemD, oui.


Qu'en sera-t-il de la commande service machin (start | restant | stop | reload 
) ?


C'est remplacé par

systemctl (start|restart|stop|reload) le_nom_du_service


Au plaisir,


itou

Re: systemd et fichiers dans /etc/init.d/

[Ph. Gras]

Hello there!

>> Je ne sais pas si ça sert encore.  Mais il semble être trop tôt pour 
>> l'enlever:

Ainsi, le répertoire init.d et tout ce qui s'y trouve devraient disparaître à 
terme ?

Qu'en sera-t-il de la commande service machin (start | restant | stop | reload 
) ?

Au plaisir,

Ph. Gras

Re: systemd et fichiers dans /etc/init.d/

[steve]

Le 30-01-2018, à 20:13:16 +0900, Charles Plessy a écrit :


Le 30-01-2018, à 11:00:44 +0900, Charles Plessy a écrit :
>
> dpkg -S /etc/init.d/* | grep "no path"


Le Tue, Jan 30, 2018 at 09:05:02AM +0100, steve a écrit :


dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.boot
dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.start
dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.stop


man insserv

Je ne sais pas si ça sert encore.  Mais il semble être trop tôt pour l'enlever:

$ sudo apt purge insserv
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
 systemd-shim
The following packages will be REMOVED:
 init* initscripts* insserv* systemd-sysv* sysv-rc*
The following NEW packages will be installed:
 systemd-shim
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
 init systemd-sysv (due to init)


A étudier donc…


dpkg-query: aucun chemin ne correspond à /etc/init.d/plexmediaserver.dpkg-bak


Bon à effacer


En effet.


Le 30-01-2018, à 11:00:44 +0900, Charles Plessy a écrit :
>
> PS: si tu veux faire un peu plus de nettoyage, regarde du coté de
> systemd-network, qui permettra d'enlever des fichiers comme
> /etc/network/interfaces (à moins que network-manager tourne déjà sur
> la machine).


Le Tue, Jan 30, 2018 at 09:05:02AM +0100, steve a écrit :


Je n'ai rien qui ressemble à un paquet nommé ainsi.


(désolé pour le « d » manquant)

$ dpkg -S systemd-networkd
systemd: /lib/systemd/systemd-networkd-wait-online
systemd: /lib/systemd/systemd-networkd
systemd: /lib/systemd/system/systemd-networkd.socket
systemd: /usr/share/man/man8/systemd-networkd-wait-online.8.gz
systemd: /usr/share/man/man8/systemd-networkd-wait-online.service.8.gz
systemd: /usr/share/man/man8/systemd-networkd.service.8.gz
systemd: /lib/systemd/system/systemd-networkd-wait-online.service
systemd: /lib/systemd/system/systemd-networkd.service
systemd: /usr/share/man/man8/systemd-networkd.8.gz


Argh, je cherchais un paquet nommé ainsi…


Merci pour les précisions.

Steve

Re: systemd et fichiers dans /etc/init.d/

[Charles Plessy]

> Le 30-01-2018, à 11:00:44 +0900, Charles Plessy a écrit :
> > 
> > dpkg -S /etc/init.d/* | grep "no path"

Le Tue, Jan 30, 2018 at 09:05:02AM +0100, steve a écrit :
> 
> dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.boot
> dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.start
> dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.stop

man insserv

Je ne sais pas si ça sert encore.  Mais il semble être trop tôt pour l'enlever:

$ sudo apt purge insserv
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  systemd-shim
The following packages will be REMOVED:
  init* initscripts* insserv* systemd-sysv* sysv-rc*
The following NEW packages will be installed:
  systemd-shim
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  init systemd-sysv (due to init)
  

> dpkg-query: aucun chemin ne correspond à /etc/init.d/plexmediaserver.dpkg-bak

Bon à effacer


> Le 30-01-2018, à 11:00:44 +0900, Charles Plessy a écrit :
> > 
> > PS: si tu veux faire un peu plus de nettoyage, regarde du coté de
> > systemd-network, qui permettra d'enlever des fichiers comme
> > /etc/network/interfaces (à moins que network-manager tourne déjà sur
> > la machine).

Le Tue, Jan 30, 2018 at 09:05:02AM +0100, steve a écrit :
> 
> Je n'ai rien qui ressemble à un paquet nommé ainsi.

(désolé pour le « d » manquant)

$ dpkg -S systemd-networkd
systemd: /lib/systemd/systemd-networkd-wait-online
systemd: /lib/systemd/systemd-networkd
systemd: /lib/systemd/system/systemd-networkd.socket
systemd: /usr/share/man/man8/systemd-networkd-wait-online.8.gz
systemd: /usr/share/man/man8/systemd-networkd-wait-online.service.8.gz
systemd: /usr/share/man/man8/systemd-networkd.service.8.gz
systemd: /lib/systemd/system/systemd-networkd-wait-online.service
systemd: /lib/systemd/system/systemd-networkd.service
systemd: /usr/share/man/man8/systemd-networkd.8.gz

Amicalement,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japon

Re: systemd et fichiers dans /etc/init.d/

[steve]

Le 30-01-2018, à 11:00:44 +0900, Charles Plessy a écrit :


Le Mon, Jan 29, 2018 at 05:16:32PM +0100, steve a écrit :


M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
principale), je me demandais si les fichiers placés dans /etc/init.d/
sont encore utilisés ou s'ils ne sont là que pour une éventuelle
compatibilité avec les systèmes utilisant SysVInit plutôt que systemd.

Dans la négative, y a-t-il un moyen propre de nettoyer le système de ces
fichiers inutiles ? Je veux dire, sans 'rm -rf /etc/init.d', car ces
fichiers sont présents dans les paquets Debian. Je sais qu'ils prennent
une place plus que négligeable, mais ce serait quand même plus élégant
de ne plus avoir de restes de l'ancien système.


Salut Steve,

la commande suivante t'indiquera quels fichiers ne sont pas installés
par un paquet.

dpkg -S /etc/init.d/* | grep "no path"


dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.boot
dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.start
dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.stop
dpkg-query: aucun chemin ne correspond à /etc/init.d/plexmediaserver.dpkg-bak



Les autres peuvent rester: le responsable du paquet s'occupe (à son
rythme) de la migration vers systemd et conserve (autant que possible)
les scripts sysvinit pour les installations utilisant ce système.



On peut voir quels services n'ont pas encore été migrés en listant
les fichiers se trouvant dans `/run/systemd/generator.late/`.


acct.service
cpufrequtils.service
fetchmail.service
geneweb.service
graphical.target.wants
gwsetup.service
hddtemp.service
loadcpufreq.service
multi-user.target.wants
ntp.service
speech-dispatcher.service
stunnel4.service
sysstat.service


Merci, c'est très intéressant.



Donc grosso-modo, si tu n'as rien installé par toi-meme hors du
système de paquets, il n'y a rien à enlever.


Ok.


PS: si tu veux faire un peu plus de nettoyage, regarde du coté de
systemd-network, qui permettra d'enlever des fichiers comme
/etc/network/interfaces (à moins que network-manager tourne déjà sur
la machine).


Je n'ai rien qui ressemble à un paquet nommé ainsi.


Encore merci pour ces renseignements.

Belle journée
Steve

Re: systemd et fichiers dans /etc/init.d/

[steve]

Le 29-01-2018, à 19:12:17 +0100, BERTRAND Joël a écrit :


steve a écrit :


Salut,


'soir



M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
principale), je me demandais si les fichiers placés dans /etc/init.d/
sont encore utilisés ou s'ils ne sont là que pour une éventuelle
compatibilité avec les systèmes utilisant SysVInit plutôt que systemd.

Dans la négative, y a-t-il un moyen propre de nettoyer le système de ces
fichiers inutiles ? Je veux dire, sans 'rm -rf /etc/init.d', car ces
fichiers sont présents dans les paquets Debian. Je sais qu'ils prennent
une place plus que négligeable, mais ce serait quand même plus élégant
de ne plus avoir de restes de l'ancien système.


Surtout pas, malheureux ! Le blob systemd va rechercher les modules
dans /lib/systemd mais s'il ne trouve rien, il convertit à la volée ce
qui est dans /etc/init.d dans son format pour tenter de faire
difficillement ce que l'ancien init SysV faisait très simplement. Ce qui
permet d'ailleurs des effets de bord assez rigolos entre deux versions
de la chose.


Du genre ? As-tu des exemples concrets ?



La seule chose qui peut à la rigueur être faite, c'est de virer de
/etc/init.d ce qui est explicitement transcrit dans /lib/systemd pour le
fonctionnement de l'usine à gaz avec des fuites.


Mais ces fichiers seront réinstallés à la prochaine maj. Donc assez
inutile.



PS: oui, je pense que ça s'est vu que je n'aime pas cette bouse... Et
plus je rentre dedans, pire c'est.


Rien à lui reprocher pour le moment pour un usage domestique.

Re: systemd et fichiers dans /etc/init.d/

[Charles Plessy]

Le Mon, Jan 29, 2018 at 05:16:32PM +0100, steve a écrit :
> 
> M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
> principale), je me demandais si les fichiers placés dans /etc/init.d/
> sont encore utilisés ou s'ils ne sont là que pour une éventuelle
> compatibilité avec les systèmes utilisant SysVInit plutôt que systemd.
> 
> Dans la négative, y a-t-il un moyen propre de nettoyer le système de ces
> fichiers inutiles ? Je veux dire, sans 'rm -rf /etc/init.d', car ces
> fichiers sont présents dans les paquets Debian. Je sais qu'ils prennent
> une place plus que négligeable, mais ce serait quand même plus élégant
> de ne plus avoir de restes de l'ancien système.

Salut Steve,

la commande suivante t'indiquera quels fichiers ne sont pas installés
par un paquet.

dpkg -S /etc/init.d/* | grep "no path"

Les autres peuvent rester: le responsable du paquet s'occupe (à son
rythme) de la migration vers systemd et conserve (autant que possible)
les scripts sysvinit pour les installations utilisant ce système.

On peut voir quels services n'ont pas encore été migrés en listant
les fichiers se trouvant dans `/run/systemd/generator.late/`.

Donc grosso-modo, si tu n'as rien installé par toi-meme hors du
système de paquets, il n'y a rien à enlever.

PS: si tu veux faire un peu plus de nettoyage, regarde du coté de
systemd-network, qui permettra d'enlever des fichiers comme
/etc/network/interfaces (à moins que network-manager tourne déjà sur
la machine).

Amicalement,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japon

Re: systemd et fichiers dans /etc/init.d/

[didier gaumet]

Le 29/01/2018 à 17:16, steve a écrit :
> 
> Salut,
> 
> 
> M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
> principale), je me demandais si les fichiers placés dans /etc/init.d/
> sont encore utilisés ou s'ils ne sont là que pour une éventuelle
> compatibilité avec les systèmes utilisant SysVInit plutôt que systemd.
> 
> Dans la négative, y a-t-il un moyen propre de nettoyer le système de ces
> fichiers inutiles ? Je veux dire, sans 'rm -rf /etc/init.d', car ces
> fichiers sont présents dans les paquets Debian. Je sais qu'ils prennent
> une place plus que négligeable, mais ce serait quand même plus élégant
> de ne plus avoir de restes de l'ancien système.
> 
> 
> Merci
> 
> Steve
> 
> 
> 

d'après
https://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/

"[...]
Q: I have a native systemd service file and a SysV init script installed
which share the same basename, e.g.
/usr/lib/systemd/system/foobar.service vs. /etc/init.d/foobar -- which
one wins?

A: If both files are available the native unit file always takes
precedence and the SysV init script is ignored, regardless whether
either is enabled or disabled. Note that a SysV service that is enabled
but overridden by a native service does not have the effect that the
native service would be enabled, too. Enabling of native and SysV
services is completely independent. Or in other words: you cannot enable
a native service by enabling a SysV service by the same name, and if a
SysV service is enabled but the respective native service is not, this
will not have the effect that the SysV script is executed.
[...]"

ce qui semble indiquer que tu peux retirer toute ce qui est présent dans
/etc/init.d/ pour lequel tu peux trouver un équivalent fonctionnel dans
/usr/lib/systemd/system/ (pas forcément avec le même nom).

Re: systemd et fichiers dans /etc/init.d/

[BERTRAND Joël]

steve a écrit :
> 
> Salut,

'soir

> 
> M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
> principale), je me demandais si les fichiers placés dans /etc/init.d/
> sont encore utilisés ou s'ils ne sont là que pour une éventuelle
> compatibilité avec les systèmes utilisant SysVInit plutôt que systemd.
> 
> Dans la négative, y a-t-il un moyen propre de nettoyer le système de ces
> fichiers inutiles ? Je veux dire, sans 'rm -rf /etc/init.d', car ces
> fichiers sont présents dans les paquets Debian. Je sais qu'ils prennent
> une place plus que négligeable, mais ce serait quand même plus élégant
> de ne plus avoir de restes de l'ancien système.

Surtout pas, malheureux ! Le blob systemd va rechercher les modules
dans /lib/systemd mais s'il ne trouve rien, il convertit à la volée ce
qui est dans /etc/init.d dans son format pour tenter de faire
difficillement ce que l'ancien init SysV faisait très simplement. Ce qui
permet d'ailleurs des effets de bord assez rigolos entre deux versions
de la chose.

La seule chose qui peut à la rigueur être faite, c'est de virer de
/etc/init.d ce qui est explicitement transcrit dans /lib/systemd pour le
fonctionnement de l'usine à gaz avec des fuites.

Cordialement,

JKB

PS: oui, je pense que ça s'est vu que je n'aime pas cette bouse... Et
plus je rentre dedans, pire c'est.

systemd et fichiers dans /etc/init.d/

[steve]

Salut,


M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
principale), je me demandais si les fichiers placés dans /etc/init.d/
sont encore utilisés ou s'ils ne sont là que pour une éventuelle
compatibilité avec les systèmes utilisant SysVInit plutôt que systemd.

Dans la négative, y a-t-il un moyen propre de nettoyer le système de ces
fichiers inutiles ? Je veux dire, sans 'rm -rf /etc/init.d', car ces
fichiers sont présents dans les paquets Debian. Je sais qu'ils prennent
une place plus que négligeable, mais ce serait quand même plus élégant
de ne plus avoir de restes de l'ancien système.


Merci

Steve

Re: Systemd et scripts /etc/init.d/.

[Dominique Dumont]

Le dimanche 8 novembre 2015, 12:29:24 12:29:24 Francois Lafont a écrit :
> Ah, donc si on veut se créer un service hors package, on doit
> mettre son fichier unité dans /etc/systemd/ pas dans /lib/systemd,
> c'est bien ça ?

En local, oui.

Tu peux aussi créer des services user dans ~/.config/systemd/user/
cf. systemd.unit(5)

HTH

-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org

Re: Systemd et scripts /etc/init.d/.

[Francois Lafont]

On 15/11/2015 15:17, Dominique Dumont wrote:

>> Ah, donc si on veut se créer un service hors package, on doit
>> mettre son fichier unité dans /etc/systemd/ pas dans /lib/systemd,
>> c'est bien ça ?
> 
> En local, oui.
> 
> Tu peux aussi créer des services user dans ~/.config/systemd/user/
> cf. systemd.unit(5)

Ok, merci pour les infos. Mais qu'est-ce que tu appeles « en local » ?
Je ne vois pas trop.


-- 
François Lafont

Re: Systemd et scripts /etc/init.d/.

[Francois Lafont]

On 08/11/2015 10:53, Sylvain L. Sauvage wrote:

>> ou dans /lib/systemd...
> 
>   Plutôt dans /etc/systemd.
> 
>   /lib/systemd contient la version par défaut, qui est fournie 
> par le paquet et qui devrait rester immuable.
>   /etc/systemd contient ce qui est local.

Ah, donc si on veut se créer un service hors package, on doit
mettre son fichier unité dans /etc/systemd/ pas dans /lib/systemd,
c'est bien ça ?

-- 
François Lafont

Re: Systemd et scripts /etc/init.d/.

[maderios]

On 11/08/2015 03:42 AM, Francois Lafont wrote:


Pour moi, c'est au cas par cas, en fonction du paquet. Ce que j'ai compris,
c'est que de toute façon c'est toujours systemd qui lance le service sous
Jessie, que le package propose ou non un script init.d (c'est le côté un
peu facho de systemd ;)).

Bonjour
Précision à rectifier si besoin: l'init Systemd utilisé actuellement en 
2015 par Debian a conservé un morceau de Sysvinit et il préserve la 
compatibilité avec ce dernier. En conséquence, toutes les 
fonctionnalités d'un "pur" Systemd ne sont pas disponibles. Il a été 
officiellement annoncé chez Fedora que leur prochaine version, F24 
(printemps 2016) utilisera un "pur" Systemd.


--
Maderios

Re: Systemd et scripts /etc/init.d/.

[Sylvain L. Sauvage]

Le dimanche 8 novembre 2015, 12:29:24 Francois Lafont a écrit :
>[…]  
> >   /lib/systemd contient la version par défaut, qui est
> > fournie par le paquet et qui devrait rester immuable.
> > 
> >   /etc/systemd contient ce qui est local.
> 
> Ah, donc si on veut se créer un service hors package, on doit
> mettre son fichier unité dans /etc/systemd/ pas dans
> /lib/systemd, c'est bien ça ?

  Créer un service local ou modifier un service distribué : /etc 
est prioritaire sur /lib (remplacer le lien dans /etc vers /lib 
par un lien vers /dev/null est une façon simple de complètement 
arrêter, désactiver et supprimer un service).

  Conserver /lib « brut de dépaquetage » peut aussi faciliter la 
vie de l’admin (sauvegarde, gestion des màj…).

  Après, chacun fait ce qui lui plaît…

-- 
 Sylvain Sauvage

Re: Systemd et scripts /etc/init.d/.

[Sylvain L. Sauvage]

Le samedi 7 novembre 2015, 22:01:30 Migrec a écrit :
>[…]
> Ce qui m'embête avec cette histoire de systemd, c'est que on
> ne sait plus vraiment si la config doit être dans
> /etc/init.d/

  Seulement si on ne veut utiliser que la compatibilité sysV.

> ou dans /lib/systemd...

  Plutôt dans /etc/systemd.

  /lib/systemd contient la version par défaut, qui est fournie 
par le paquet et qui devrait rester immuable.
  /etc/systemd contient ce qui est local.

(/etc/systemd contient des liens vers /lib/systemd mais, d’après 
 ce que je comprends, ils ne sont pas nécessaires, juste
 pratiques.)

-- 
 Sylvain Sauvage

Re: Systemd et scripts /etc/init.d/.

[Vincent Lefevre]

On 2015-11-08 12:29:24 +0100, Francois Lafont wrote:
> Ah, donc si on veut se créer un service hors package, on doit
> mettre son fichier unité dans /etc/systemd/ pas dans /lib/systemd,
> c'est bien ça ?

Ce n'est pas propre à systemd. Ce qui est dans /lib est réservé aux
paquets Debian.

Concernant tout ce qui est local:
  * Pour systemd, reste la possibilité de /etc/systemd.
  * Pour les bibliothèques, utiliser /usr/local/lib au lieu de /lib
ou /usr/lib.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Systemd et scripts /etc/init.d/.

[Migrec]

Le Sunday 08 November 2015, 18:27:58 Vincent Lefevre a écrit :
> On 2015-11-08 12:29:24 +0100, Francois Lafont wrote:
> > Ah, donc si on veut se créer un service hors package, on doit
> > mettre son fichier unité dans /etc/systemd/ pas dans /lib/systemd,
> > c'est bien ça ?
> 
> Ce n'est pas propre à systemd. Ce qui est dans /lib est réservé aux
> paquets Debian.
> 
> Concernant tout ce qui est local:
>   * Pour systemd, reste la possibilité de /etc/systemd.
>   * Pour les bibliothèques, utiliser /usr/local/lib au lieu de /lib
> ou /usr/lib.

Merci pour vos réponses. J'ai bien compris qu'on était encore dans un double 
système mais que c'est bien systemd qui lance les services...

Encore une chose : Quel est le service qui parcourt /etc/init.d/ à la 
recherche de scripts éventuellement non lancés via systemd "pur" ??

Re: Systemd et scripts /etc/init.d/.

[Vincent Lefevre]

On 2015-11-08 20:04:45 +0100, Migrec wrote:
> Encore une chose : Quel est le service qui parcourt /etc/init.d/ à la 
> recherche de scripts éventuellement non lancés via systemd "pur" ??

Je pense que ça ne peut pas être un service puisque cela risquerait
d'aboutir à des incohérences dans les dépendances.

On peut trouver des infos ici:

http://unix.stackexchange.com/questions/233468/how-does-systemd-use-etc-init-d-scripts

Je n'ai pas tout lu, mais en gros, il y a un programme
systemd-sysv-generator appelé assez tôt dans la séquence de boot
(je suppose, avant tout service), qui convertit les scripts de
/etc/init.d (LSB) en services pour systemd et les stocke dans
/run/systemd/system.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Systemd et scripts /etc/init.d/.

[Migrec]

Le Friday 06 November 2015, 18:34:22 Francois Lafont a écrit :
> 
> Pour faire de mon script un véritable daemon géré par systemd,
> j'ai juste à créer le fichier /lib/systemd/system/myservice.service
> et y mettre ceci :
> 
> -
> [Unit]
> Description=My personal service
> After=network.target
> 
> [Service]
> User=toto
> Group=toto
> PIDFile=/var/lib/toto/myservice.pid
> ExecStart=/usr/local/bin/myservice
> Restart=on-failure
> 
> [Install]
> WantedBy=multi-user.target
> -
> 
> Puis :
> 
> systemctl enable myservice # activation du démarrage automatique du
> service à chaque boot systemctl start myservice  # démarrage du service

Ce qui m'embête avec cette histoire de systemd, c'est que on ne sait plus 
vraiment si la config doit être dans /etc/init.d/ ou dans /lib/systemd...

Et j'ai quand même l'impression que beaucoup de paquets n'y sont pas encore 
passés (backuppc, etc.).

Re: Systemd et scripts /etc/init.d/.

[Vincent Lefevre]

On 2015-11-07 22:01:30 +0100, Migrec wrote:
> Ce qui m'embête avec cette histoire de systemd, c'est que on ne sait plus 
> vraiment si la config doit être dans /etc/init.d/ ou dans /lib/systemd...

Normalement, les paquets devraient fournir les deux, car toutes
les machines ne sont pas sous systemd.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Systemd et scripts /etc/init.d/.

[Francois Lafont]

Ci-dessous, je tente d'expliquer ce que je comprends de systemd.
Mais je découvre moi-même en ce moment alors si je dis des bêtises
j'accepte avec grand plaisir toute rectification. ;)

On 07/11/2015 22:01, Migrec wrote:

> Ce qui m'embête avec cette histoire de systemd, c'est que on ne sait plus 
> vraiment si la config doit être dans /etc/init.d/ ou dans /lib/systemd...

Pour moi, c'est au cas par cas, en fonction du paquet. Ce que j'ai compris,
c'est que de toute façon c'est toujours systemd qui lance le service sous
Jessie, que le package propose ou non un script init.d (c'est le côté un
peu facho de systemd ;)). Ensuite, tu dois mettre la main sur le fichier
unité pour comprendre comment réellement le service est lancé. Par exemple
ssh :

~# systemctl show ssh.service | grep FragmentPath
FragmentPath=/lib/systemd/system/ssh.service

Le fichier unité est /lib/systemd/system/ssh.service et dedans on peut y
voir :

ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

Donc le script init.d n'est absolument pas utilisé par le système
pour démarrer le service. systemd passe passe directement par le
binaire /usr/sbin/sshd (tu remarqueras que pourtant le paquet
openssh-server fournit bien un script init.d mais celui-ci n'est
donc pas utilisé).

Maintenant, prends par exemple le service MySQL :

~# systemctl show mysql.service | grep FragmentPath
FragmentPath=/run/systemd/generator.late/mysql.service

Le fichier unité n'est pas dans /lib/systemd mais dans /run car
c'est un fichier qui est généré (par systemd je pense) au moment
du démarrage du système. Si tu regardes ce fichier, tu verras :

ExecStart=/etc/init.d/mysql start
ExecStop=/etc/init.d/mysql stop

Là, on peut constater que le script init.d est bel et bien
utilisé par systemd pour lancer le service MySQL. C'est comme
ça, si j'ai bien compris, que systemd gère les services qui ne
démarrent qu'avec des scripts sysvinit. Et cette gestion est
d'ailleurs un peu tordue car j'ai cru comprendre qu'ensuite le
script init.d, via des inclusions de libs, fait lui-même appel
à son tour à systemd. Bref, ça semble super sioux et d'après ce
que je comprends ce n'est pas le cas idéal. Si c'est possible,
c'est bien mieux que systemd puisse démarrer un service via le
binaire directement (et avec un binaire qui ne forke pas, ie
qui ne rend pas la main).

> Et j'ai quand même l'impression que beaucoup de paquets n'y sont pas encore 
> passés (backuppc, etc.).

C'est mon impression également. Par exemple, MySQL et Apache2 (c'est
pas n'importe quoi comme services) passent encore par une script
init.d sous Jessie. Après, j'imagine que c'est pas toujours simple
de passer le service à un démarrage via systemd. J'imagine que ça se
fera avec le temps.

Par contre, ce que je pense, c'est que si toi tu veux te créer un
petit service sous Jessie, tu as tout intérêt à le faire sans passer
par un script init.d et en utilisant un fichier unité systemd.
C'est vraiment nettement plus simple (cf mon message précédent) et
en plus je pense que ton service sera (nettement) mieux géré par
systemd dans ce cas là que si systemd doit gérer ton script init.d.

-- 
François Lafont

Systemd et scripts /etc/init.d/.

[Migrec]

Bonjour,

Je me suis documenté sur le systemd mais j'ai encore quelques question 
pratiques...

Sur mon serveur mis à jour depuis peu en version stable, le nouveau systemd a 
remplacé l'ancien système. J'ai un soucis avec un script "perso" qui est dans 
/etc/init.d/fwbuilder

Pourquoi est-il exécuté ? Il me semble que ce n'est pas l'emplacement des 
"unités" ?

Le script tel quel ne passe pas car il manque les tag LSB ? Si je les rajoute 
dans /etc/insserv/overrides/fwbuilder, ils seront rajoutés au script /etc/
init.d/fwbuilder, c'est ça ?

Cordialement,

PS : Mon script fwbuilder est en fait déposé dans /etc/init.d/ via ssh depuis 
une autre machine.

Re: Systemd et scripts /etc/init.d/.

[David Guyot]

Bonjour.

En fait, par défaut, en tout cas sous Debian, systemd va émuler le
fonctionnement d'init, en ce qu'il utilisera les scripts init.d même
s'ils ne sont pas des unités systemd à proprement parler. Évidemment,
toutes les fonctionnalités de systemd ne fonctionneront pas sur les
scripts init.d, mais on peut au moins les lancer, les redémarrer et les
arrêter.

Pour le reste, je ne sais pas.

Cordialement.

Le vendredi 06 novembre 2015 à 15:52 +0100, Migrec a écrit :
> Bonjour,
> 
> Je me suis documenté sur le systemd mais j'ai encore quelques question 
> pratiques...
> 
> Sur mon serveur mis à jour depuis peu en version stable, le nouveau systemd a 
> remplacé l'ancien système. J'ai un soucis avec un script "perso" qui est dans 
> /etc/init.d/fwbuilder
> 
> Pourquoi est-il exécuté ? Il me semble que ce n'est pas l'emplacement des 
> "unités" ?
> 
> Le script tel quel ne passe pas car il manque les tag LSB ? Si je les rajoute 
> dans /etc/insserv/overrides/fwbuilder, ils seront rajoutés au script /etc/
> init.d/fwbuilder, c'est ça ?
> 
> Cordialement,
> 
> PS : Mon script fwbuilder est en fait déposé dans /etc/init.d/ via ssh depuis 
> une autre machine.
> 

-- 
David Guyot
Administrateur système, réseau et télécom / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
03 29 30 47 85


signature.asc
Description: This is a digitally signed message part

Re: Systemd et scripts /etc/init.d/.

[Francois Lafont]

Bonjour,

On 06/11/2015 15:52, Migrec wrote:

> Je me suis documenté sur le systemd mais j'ai encore quelques question 
> pratiques...
> 
> Sur mon serveur mis à jour depuis peu en version stable, le nouveau systemd a 
> remplacé l'ancien système. J'ai un soucis avec un script "perso" qui est dans 
> /etc/init.d/fwbuilder
> 
> Pourquoi est-il exécuté ? Il me semble que ce n'est pas l'emplacement des 
> "unités" ?

Mais systemd est capable (en théorie) de gérer le démarrage etc. des scripts
sysvinit (ie des scripts dans /etc/init.d/). Donc ça semble logique ce que tu
dis.

Après dans la pratique, le peu que j'ai regardé, la prise en charge des
scripts sysvinit par systemd semble relever de la bidouille complète. Je
me rappelle avoir vu un script init.d lancé par systemd via le fichier
/etc/init.d/le-script (normal jusque là) mais le script init.d lui même
ensuite faisait appel à systemd. Bref, ça avait l'air vraiment très très
"sioux". ;)

Après, je ne fais pas partie des anti-systemd, pas du tout. Je pense
que la plupart des soucis que les gens rencontrent viennent justement
de scripts init.d dont la prise en charge de systemd me semble pas
super fiable en soi.

Bref, tout ça pour dire que si tu es sous systemd tu devrais laisser
tomber ton script init.d et utiliser systemd directement via une
une unité. Pour le coup (et c'est un des gros intérêts de systemd)
c'est vraiment très simple à écrire. Et là, tu auras une prise
en charge de ton service par systemd qui sera, je pense, correcte.

> Le script tel quel ne passe pas car il manque les tag LSB ? Si je les rajoute 
> dans /etc/insserv/overrides/fwbuilder, ils seront rajoutés au script /etc/
> init.d/fwbuilder, c'est ça ?

Pour moi, si tu veux activer un service lancé par un script init.d c'est :

update-rc.d le-service defaults

Si tu fais ça et si tu as bien tes entêtes LSB, le service devrait
bien être activé et systemd devrait normalement tentera de lancer
le service au boot. Après, comme je disais précédemment, la prise en
charge des scripts sysvinit par systemd ne me semble pas solide comme
un roc. Et force est de constater qu'au niveau des packages beaucoup
restent encore sur du sysvinit (mais c'est normal, ça se fera avec
le temps).

-- 
François Lafont

Re: Systemd et scripts /etc/init.d/.

[Francois Lafont]

Re,

On 06/11/2015 17:06, Francois Lafont wrote:

> Bref, tout ça pour dire que si tu es sous systemd tu devrais laisser
> tomber ton script init.d et utiliser systemd directement via une
> une unité. Pour le coup (et c'est un des gros intérêts de systemd)
> c'est vraiment très simple à écrire. Et là, tu auras une prise
> en charge de ton service par systemd qui sera, je pense, correcte.

Juste pour te donner un exemple. Sous Debian Jessie, j'ai un script
/usr/local/bin/myservice qui est une sorte de daemon dans le sens
où il ne rend jamais la main (c'est important avec systemd, apparemment
il vaut mieux que le binaire ne rende pas la main ce qui, au passage,
rend l'écriture du script encore plus facile). En gros, le script c'est
un simple :

-
while true
do
   ...
done
-

Pour faire de mon script un véritable daemon géré par systemd,
j'ai juste à créer le fichier /lib/systemd/system/myservice.service
et y mettre ceci :

-
[Unit]
Description=My personal service
After=network.target

[Service]
User=toto
Group=toto
PIDFile=/var/lib/toto/myservice.pid
ExecStart=/usr/local/bin/myservice
Restart=on-failure

[Install]
WantedBy=multi-user.target
-

Puis :

systemctl enable myservice # activation du démarrage automatique du service 
à chaque boot
systemctl start myservice  # démarrage du service

Et c'est fini. C'est quand même plutôt simple je trouve.

Ceci étant je ne suis pas un expert systemd, et si j'ai dit des
bêtises, je serais ravi d'avoir vos remarques. ;)


-- 
François Lafont

Re: firewall à base d'iptables au démarrage (/etc/init.d/)

[François TOURDE]

Le 15949ième jour après Epoch,
Gaëtan PERRIER écrivait:

 Bonsoir,

 C'est possible quand on est sur un réseau statique mais avec une réseau
 en dhcp ça ne me semble pas possible, non ?

Idem qu'en statique, sauf que la ligne de l'interface est du style

 auto eth0
 iface eth0 inet dhcp
  pre-up /usr/local/sbin/firewall.sh

Et sinon, il y a comme répondu déjà le répertoire if-up.d dans
/etc/network/

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppst9djc@tourde.org

Re: firewall à base d'iptables au démarrage (/etc/init.d/)

[Jean Baptiste FAVRE]

Bonjour,

Là encore, je pense que if-pre-up.d serait plus indiqué.

De cette manière, le firewall est appliqué avant l'activation de
l'interface :)

Cordialement,
JB

Le 01/09/2013 10:00, François TOURDE a écrit :
 Le 15949ième jour après Epoch, Gaëtan PERRIER écrivait:
 
 Bonsoir,
 
 C'est possible quand on est sur un réseau statique mais avec une
 réseau en dhcp ça ne me semble pas possible, non ?
 
 Idem qu'en statique, sauf que la ligne de l'interface est du style
 
 auto eth0 iface eth0 inet dhcp pre-up
 /usr/local/sbin/firewall.sh
 
 Et sinon, il y a comme répondu déjà le répertoire if-up.d dans 
 /etc/network/
 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/52230212.1030...@jbfavre.org

Re: firewall à base d'iptables au démarrage (/etc/init.d/)

[Dominique Asselineau]

François TOURDE wrote on Sun, Sep 01, 2013 at 10:00:55AM +0200
 Le 15949ième jour après Epoch,
 Gaëtan PERRIER écrivait:
 
  Bonsoir,
 
  C'est possible quand on est sur un réseau statique mais avec une réseau
  en dhcp ça ne me semble pas possible, non ?
 
 Idem qu'en statique, sauf que la ligne de l'interface est du style
 
  auto eth0
  iface eth0 inet dhcp
 pre-up /usr/local/sbin/firewall.sh
 
 Et sinon, il y a comme répondu déjà le répertoire if-up.d dans
 /etc/network/

Désolé, j'ai oublié de préciser qu'il s'agissait d'un VPS qui a donc
une IP statique.

À propos du rép. /etc/network/if-up-d/, le rép.
/etc/network/if-pre-up-d/ ne serait-il pas plus approprié ?

Comme il s'agit d'un VPS sur lequel j'ai plusieurs services (Apache2,
MySQL uniquement en accès local, SMTP), la solution /ec/rc?.d/ ne
serait-elle pas plus adaptée/précise ?  En forçant l'exécution des
règles iptables, avant le démarrage du réseau à l'aide des dépendances
gérées par insserv.

dom 

--

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130901091045.ga32...@telecom-paristech.fr

Re: firewall à base d'iptables au démarrage (/etc/init.d/)

[daniel huhardeaux]

Bonjour,*

*Le 01/09/2013 10:00, François TOURDE a écrit :

Le 15949ième jour après Epoch,
Gaëtan PERRIER écrivait:


Bonsoir,

C'est possible quand on est sur un réseau statique mais avec une réseau
en dhcp ça ne me semble pas possible, non ?

Idem qu'en statique, sauf que la ligne de l'interface est du style


auto eth0
iface eth0 inet dhcp
pre-up /usr/local/sbin/firewall.sh

Et sinon, il y a comme répondu déjà le répertoire if-up.d dans
/etc/network/


Saulf que en pre-up et dhcp, si les règles sont basées sur l IP 
publique, celle ci n'est pas encore connue, il faut donc le faire en 2 
temps: pre-up protège l'interface, post-up pour les règles liées à 
l'adresse IP

--
Daniel

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/522329a3.3080...@tootai.net

Re: firewall à base d'iptables au démarrage (/etc/init.d/)

[Gaëtan PERRIER]

Le Sun, 01 Sep 2013 13:48:51 +0200
daniel huhardeaux no-s...@tootai.net a écrit:

 Bonjour,*
 
 *Le 01/09/2013 10:00, François TOURDE a écrit :
  Le 15949ième jour après Epoch,
  Gaëtan PERRIER écrivait:
 
  Bonsoir,
 
  C'est possible quand on est sur un réseau statique mais avec une
  réseau en dhcp ça ne me semble pas possible, non ?
  Idem qu'en statique, sauf que la ligne de l'interface est du style
 
  auto eth0
  iface eth0 inet dhcp
pre-up /usr/local/sbin/firewall.sh
  Et sinon, il y a comme répondu déjà le répertoire if-up.d dans
  /etc/network/
 
 Saulf que en pre-up et dhcp, si les règles sont basées sur l IP 
 publique, celle ci n'est pas encore connue, il faut donc le faire en
 2 temps: pre-up protège l'interface, post-up pour les règles liées à 
 l'adresse IP

Oui c'était ça mon point d'interrogation. Vu que l'IP n'est pas connue
il est difficile de créer une règle iptable dessus ...
Et maintenant comment faites-vous avec une machine qui bouge beaucoup
comme un portable avec network-manager ? J'utilise le dispatcher avec
des règles sur up et dhcp4-change mais du coup ça n'intervient qu'après
que l'interface soit active.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130901145930.dd32a0dfdd69618d6bae5...@neuf.fr

Re: firewall à base d'iptables au démarrage (/etc/init.d/)

[Pascal Hambourg]

Gaëtan PERRIER a écrit :
 Le Sun, 01 Sep 2013 13:48:51 +0200
 daniel huhardeaux no-s...@tootai.net a écrit:
 Saulf que en pre-up et dhcp, si les règles sont basées sur l IP 
 publique, celle ci n'est pas encore connue, il faut donc le faire en
 2 temps: pre-up protège l'interface, post-up pour les règles liées à 
 l'adresse IP
 
 Oui c'était ça mon point d'interrogation. Vu que l'IP n'est pas connue
 il est difficile de créer une règle iptable dessus ...
 Et maintenant comment faites-vous avec une machine qui bouge beaucoup
 comme un portable avec network-manager ? J'utilise le dispatcher avec
 des règles sur up et dhcp4-change mais du coup ça n'intervient qu'après
 que l'interface soit active.

En deux temps, on t'a dit.
Avant le démarrage du réseau : on bloque tout.
Avant ou après l'activation d'une interface, peu importe : on ajoute les
règles liées à l'interface en question (qu'on n'oublie pas de supprimer
à sa désactivation n'est-ce pas).

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/5223c003.7090...@plouf.fr.eu.org

firewall à base d'iptables au démarrage (/etc/init.d/)

[Dominique Asselineau]

Bonjour,

J'ai adapté un firewall à partir de la doc de Debian security, que
j'ai placé dans /etc/init.d/ et j'aurais souhaité le faire exécuter au
bon moment lors du démarrage.

Au début du script il faut donc placer des lignes d'en-tête pour que
insserv l'insère au bon endroit dans les /etc/rc?.d/ lors d'un
update-rc.d.  Et j'ai un petit doute sur les contraintes à insérer
dans cette en-tête.

Dans la mesure où ces règles doivent protéger la machine dans le
réseau, le service réseau doit-il être opérationnel ou justement ne
doit-il pas l'être tant que ces règles ne snt pas en place ?

dom
-- 

 LocalWords:  update-rc.d snt dom

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130831202159.ga20...@telecom-paristech.fr

Re: firewall à base d'iptables au démarrage (/etc/init.d/)

[Jean Baptiste FAVRE]

Bonsoir,
Idéalement le firewall devrait être actif avant le démarrage du
réseau, pour éviter un laps de temps, si court soit-il, pendant lequel
la machine n'est pas protégée.

Personnellement, je préfère utiliser un script shell que j'appelle
dans la configuration réseau (fichier /etc/netork/interface). Par exemple:

auto eth0
iface eth0 inet static
address xxx.yyy.zzz.aaa
netmask 255.255.255.0
network xxx.yyy.zzz.0
broadcast xxx.yyy.zzz.255
gateway xxx.yyy.zzz.1
pre-up /usr/local/sbin/firewall.sh

De cette manière, le firewall est chargé avant que l'interface ne soit
activée et configurée.

Cordialement,
JB

Le 31/08/2013 22:21, Dominique Asselineau a écrit :
 Bonjour,
 
 J'ai adapté un firewall à partir de la doc de Debian security, que 
 j'ai placé dans /etc/init.d/ et j'aurais souhaité le faire exécuter
 au bon moment lors du démarrage.
 
 Au début du script il faut donc placer des lignes d'en-tête pour
 que insserv l'insère au bon endroit dans les /etc/rc?.d/ lors d'un 
 update-rc.d.  Et j'ai un petit doute sur les contraintes à insérer 
 dans cette en-tête.
 
 Dans la mesure où ces règles doivent protéger la machine dans le 
 réseau, le service réseau doit-il être opérationnel ou justement
 ne doit-il pas l'être tant que ces règles ne snt pas en place ?
 
 dom
 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/5222545c.7070...@jbfavre.org

Re: firewall à base d'iptables au démarrage (/etc/init.d/)

[Gaëtan PERRIER]

Bonsoir,

C'est possible quand on est sur un réseau statique mais avec une réseau
en dhcp ça ne me semble pas possible, non ?

Gaëtan

Le Sat, 31 Aug 2013 22:38:52 +0200
Jean Baptiste FAVRE debian...@jbfavre.org a écrit:

 Bonsoir,
 Idéalement le firewall devrait être actif avant le démarrage du
 réseau, pour éviter un laps de temps, si court soit-il, pendant lequel
 la machine n'est pas protégée.
 
 Personnellement, je préfère utiliser un script shell que j'appelle
 dans la configuration réseau (fichier /etc/netork/interface). Par
 exemple:
 
 auto eth0
 iface eth0 inet static
 address xxx.yyy.zzz.aaa
 netmask 255.255.255.0
 network xxx.yyy.zzz.0
 broadcast xxx.yyy.zzz.255
 gateway xxx.yyy.zzz.1
   pre-up /usr/local/sbin/firewall.sh
 
 De cette manière, le firewall est chargé avant que l'interface ne soit
 activée et configurée.
 
 Cordialement,
 JB
 
 Le 31/08/2013 22:21, Dominique Asselineau a écrit :
  Bonjour,
  
  J'ai adapté un firewall à partir de la doc de Debian security, que 
  j'ai placé dans /etc/init.d/ et j'aurais souhaité le faire exécuter
  au bon moment lors du démarrage.
  
  Au début du script il faut donc placer des lignes d'en-tête pour
  que insserv l'insère au bon endroit dans les /etc/rc?.d/ lors d'un 
  update-rc.d.  Et j'ai un petit doute sur les contraintes à insérer 
  dans cette en-tête.
  
  Dans la mesure où ces règles doivent protéger la machine dans le 
  réseau, le service réseau doit-il être opérationnel ou justement
  ne doit-il pas l'être tant que ces règles ne snt pas en place ?
  
  dom
  
 
 -- 
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists
 
 Pour vous DESABONNER, envoyez un message avec comme objet
 unsubscribe vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: http://lists.debian.org/5222545c.7070...@jbfavre.org


-- 
Gaëtan PERRIER gaetan.perr...@neuf.fr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130901011838.434f3ddc55f0d2e82fd82...@neuf.fr

Re: firewall à base d'iptables au démarrage (/etc/init.d/)

[Belaïd MOUNSI]

Bonjour,
Dans ce cas je pense que tu peux mettre ton script dans le répertoire
/etc/network/if-up.d .Ainsi le script est executé lors de l'initialisation
des interfaces réseaux du système.
Le 1 sept. 2013 01:18, Gaëtan PERRIER gaetan.perr...@neuf.fr a écrit :

 Bonsoir,

 C'est possible quand on est sur un réseau statique mais avec une réseau
 en dhcp ça ne me semble pas possible, non ?

 Gaëtan

 Le Sat, 31 Aug 2013 22:38:52 +0200
 Jean Baptiste FAVRE debian...@jbfavre.org a écrit:

  Bonsoir,
  Idéalement le firewall devrait être actif avant le démarrage du
  réseau, pour éviter un laps de temps, si court soit-il, pendant lequel
  la machine n'est pas protégée.
 
  Personnellement, je préfère utiliser un script shell que j'appelle
  dans la configuration réseau (fichier /etc/netork/interface). Par
  exemple:
 
  auto eth0
  iface eth0 inet static
  address xxx.yyy.zzz.aaa
  netmask 255.255.255.0
  network xxx.yyy.zzz.0
  broadcast xxx.yyy.zzz.255
  gateway xxx.yyy.zzz.1
pre-up /usr/local/sbin/firewall.sh
 
  De cette manière, le firewall est chargé avant que l'interface ne soit
  activée et configurée.
 
  Cordialement,
  JB
 
  Le 31/08/2013 22:21, Dominique Asselineau a écrit :
   Bonjour,
  
   J'ai adapté un firewall à partir de la doc de Debian security, que
   j'ai placé dans /etc/init.d/ et j'aurais souhaité le faire exécuter
   au bon moment lors du démarrage.
  
   Au début du script il faut donc placer des lignes d'en-tête pour
   que insserv l'insère au bon endroit dans les /etc/rc?.d/ lors d'un
   update-rc.d.  Et j'ai un petit doute sur les contraintes à insérer
   dans cette en-tête.
  
   Dans la mesure où ces règles doivent protéger la machine dans le
   réseau, le service réseau doit-il être opérationnel ou justement
   ne doit-il pas l'être tant que ces règles ne snt pas en place ?
  
   dom
  
 
  --
  Lisez la FAQ de la liste avant de poser une question :
  http://wiki.debian.org/fr/FrenchLists
 
  Pour vous DESABONNER, envoyez un message avec comme objet
  unsubscribe vers debian-user-french-requ...@lists.debian.org
  En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
  Archive: http://lists.debian.org/5222545c.7070...@jbfavre.org


 --
 Gaëtan PERRIER gaetan.perr...@neuf.fr

 --
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists

 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive:
 http://lists.debian.org/20130901011838.434f3ddc55f0d2e82fd82...@neuf.fr

[sid] /etc/init.d/xserver-xorg existe t il tjs chez vous ?

[giggz]

Bonjour,

je suis en sid à jour. L'arrivée de insserv qui réordonne le boot est
quelque peu stressant. Bon chez moi tout s'est à peu près bien passé,
pas de dégat. Mais j'ai des warning à chaque upgrade de paquets ayant un
fichier dans init.d.

En particulier j'ai ce warning ci :
insserv: warning: script 'S22xserver-xorg' missing LSB tags and overrides
insserv: warning: script 'xserver-xorg' missing LSB tags and overrides

j'ai bien un fichier /etc/init.d/xserver-xorg. mais la date de celui ci
me laisse à penser qu'il n'est plus trop d'actualité :

10:34 gi...@thor /etc/rcS.d % ll /etc/init.d/xserver-xorg
-rwxr-xr-x 1 root root 805 déc 29  2005 /etc/init.d/xserver-xorg*

de plus :
10:39 gi...@thor /etc/rcS.d % dpkg -S /etc/init.d/xserver-xorg
dpkg : /etc/init.d/xserver-xorg introuvable.
zsh: exit 1 dpkg -S /etc/init.d/xserver-xorg


Bref pour ceux qui ont une sid fraichement installée avec xorg dessus,
ce fichier existe t il chez vous ???

Merci d'avance
Guillaume

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: [sid] /etc/init.d/xserver-xorg existe t il tjs chez vous ?

[Courrier Debian]

Le samedi 1 août 2009 12:40:59, giggz a écrit :
 Bonjour,

 je suis en sid à jour. L'arrivée de insserv qui réordonne le boot est
 quelque peu stressant. Bon chez moi tout s'est à peu près bien passé,
 pas de dégat. Mais j'ai des warning à chaque upgrade de paquets ayant un
 fichier dans init.d.

 En particulier j'ai ce warning ci :
 insserv: warning: script 'S22xserver-xorg' missing LSB tags and overrides
 insserv: warning: script 'xserver-xorg' missing LSB tags and overrides

 j'ai bien un fichier /etc/init.d/xserver-xorg. mais la date de celui ci
 me laisse à penser qu'il n'est plus trop d'actualité :

 10:34 gi...@thor /etc/rcS.d % ll /etc/init.d/xserver-xorg
 -rwxr-xr-x 1 root root 805 déc 29  2005 /etc/init.d/xserver-xorg*

 de plus :
 10:39 gi...@thor /etc/rcS.d % dpkg -S /etc/init.d/xserver-xorg
 dpkg : /etc/init.d/xserver-xorg introuvable.
 zsh: exit 1 dpkg -S /etc/init.d/xserver-xorg


 Bref pour ceux qui ont une sid fraichement installée avec xorg dessus,
 ce fichier existe t il chez vous ???

 Merci d'avance
 Guillaume
Je suis en Sid  également et à ta question, non je n'ai pas ce fichier 
/etc/init.d/xserver-xorg , pour l'instant il semble que Sid soit en grande 
mutation avec tout ce que sa implique comme problèmes.
Chez moi je n'ai plus : aptitude, ia32-apt-get que je venais à peine 
d'installer. Actuellement Sid mérite à 200% son nom instable.
Philippe 

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: [sid] /etc/init.d/xserver-xorg existe t il tjs chez vous ?

[giggz]

Courrier Debian a écrit :
 Le samedi 1 août 2009 12:40:59, giggz a écrit :
 Bonjour,

 je suis en sid à jour. L'arrivée de insserv qui réordonne le boot est
 quelque peu stressant. Bon chez moi tout s'est à peu près bien passé,
 pas de dégat. Mais j'ai des warning à chaque upgrade de paquets ayant un
 fichier dans init.d.

 En particulier j'ai ce warning ci :
 insserv: warning: script 'S22xserver-xorg' missing LSB tags and overrides
 insserv: warning: script 'xserver-xorg' missing LSB tags and overrides

 j'ai bien un fichier /etc/init.d/xserver-xorg. mais la date de celui ci
 me laisse à penser qu'il n'est plus trop d'actualité :

 10:34 gi...@thor /etc/rcS.d % ll /etc/init.d/xserver-xorg
 -rwxr-xr-x 1 root root 805 déc 29  2005 /etc/init.d/xserver-xorg*

 de plus :
 10:39 gi...@thor /etc/rcS.d % dpkg -S /etc/init.d/xserver-xorg
 dpkg : /etc/init.d/xserver-xorg introuvable.
 zsh: exit 1 dpkg -S /etc/init.d/xserver-xorg


 Bref pour ceux qui ont une sid fraichement installée avec xorg dessus,
 ce fichier existe t il chez vous ???

 Merci d'avance
 Guillaume
 Je suis en Sid  également et à ta question, non je n'ai pas ce fichier 
 /etc/init.d/xserver-xorg , pour l'instant il semble que Sid soit en grande 
 mutation avec tout ce que sa implique comme problèmes.
 Chez moi je n'ai plus : aptitude, ia32-apt-get que je venais à peine 
 d'installer. Actuellement Sid mérite à 200% son nom instable.
 Philippe 
 

oki merci de ta réponse.

Pour aptitude...qd tu vois qu'aptitude va être supprimé par une mise à
jour d'apt. ben tu mets pas à jour apt...et tu attends patiemment que
tout s'emboite. en gros une bonne semaine...

Pour l'affaire ia32...oui ça a l'air d'être un beau bordel. bon j'ai la
chance d'être encore à l'âge de pierre avec mon 32 bits donc po de
problème :) moi c'est insserv qui me fait un peu peur...vu les rapports
de bugs des pontes debian à son sujet, vaut mieux être prudent!

bonne journée
Guillaume

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

pourquoi j'ai pas de /etc/init.d/stunnel?

[Thibaut LE LEVIER]

Bonjour à tous ou plutôt rebonjour.

Je suis toujours en train de configurer mon Postfix en trichant avec 
stunnel mais j'ai juste une petite question.
stunnel n'était pas installé sur ma machine, je l'ai donc installé avec 
aptitude mais il n'a pas crée de script de démarrage dans /etc/init.d/


quelqu'un aurai une idée ou une copie de script à me passer?

si non comment puis-je démarrer stunnel? /usr/sbin/stunnel?

Merci
Thibaut

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pourquoi j'ai pas de /etc/init.d/stunnel?

[Thibaut LE LEVIER]

Re (désolé pour le doublon)
à noté aussi que /etc/default/stunnel n'existait pas non plus et le 
dossier /etc/stunnel/ n'existait même pas!


Thibaut LE LEVIER wrote:

Bonjour à tous ou plutôt rebonjour.

Je suis toujours en train de configurer mon Postfix en trichant avec 
stunnel mais j'ai juste une petite question.
stunnel n'était pas installé sur ma machine, je l'ai donc installé 
avec aptitude mais il n'a pas crée de script de démarrage dans 
/etc/init.d/


quelqu'un aurai une idée ou une copie de script à me passer?

si non comment puis-je démarrer stunnel? /usr/sbin/stunnel?

Merci
Thibaut



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pourquoi j'ai pas de /etc/init.d/stunnel?

[Thomas Preud'homme]

The Tuesday 15 July 2008 16:00:26 Thibaut LE LEVIER, you wrote :
 Bonjour à tous ou plutôt rebonjour.

 Je suis toujours en train de configurer mon Postfix en trichant avec
 stunnel mais j'ai juste une petite question.
 stunnel n'était pas installé sur ma machine, je l'ai donc installé avec
 aptitude mais il n'a pas crée de script de démarrage dans /etc/init.d/

 quelqu'un aurai une idée ou une copie de script à me passer?

 si non comment puis-je démarrer stunnel? /usr/sbin/stunnel?

/usr/bin/stunnel plus précisément. Tu peux toujours faire un petit script qui 
lance /usr/bin/stunnel et placer ce script dans /etc/init.d ainsi que les 
invocations suivant les runlevel qui vont bien grâce à update-rc.d

Sinon tu peux backporter le paquet de testing ou unstable qui contient lui un 
script de lancement dans /etc/init.d

Le paquet se nomme alors stunnel4


 Merci
 Thibaut

Cordialement

-- 
Thomas Preud'homme

Why debian : http://www.debian.org/intro/why_debian

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [SID] /etc/init.d/xfree86-common tjs présen t...

[Jean Monnat]

giggz wrote:


Slt,







Je suis en sid (installé depuis woody...ça fait un bail). En regardant



ds /etc/init.d/ j'ai vu que xfree86-common était tjs présent. Peut on



l'enlever ss risque ?







Merci d'avance



GiGGz










Je me suis aussi posé la question et

Je l'ai éliminé sans problème

rm xfree86-common

update-rc.d xfree86-common remove


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et

Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

[SID] /etc/init.d/xfree86-common tjs présent. ..

[giggz]

Slt,

Je suis en sid (installé depuis woody...ça fait un bail). En regardant
ds /etc/init.d/ j'ai vu que xfree86-common était tjs présent. Peut on
l'enlever ss risque ?

Merci d'avance
GiGGz


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Florentin Duneau]

Le Mercredi 1 Février 2006 14:32, Florentin Duneau a écrit :
 Bonjour

 Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge pas
 la config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils
 et /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La seule solution
 pour récupérer le son est de faire /etc/init.d/alsa-utils start dans une
 console.

 Je ne comprends pas pourquoi la config n'est pas chargée lors de
 l'exécution de /etc/rcS.d/S50alsa-utils. Une idée ?

Ce matin, je démarre le pc, pas de son. Je lance kmix pour activer les 
sorties, le son est présent. Je pars manger, j'éteins la machine. Je la 
démarre de nouveau après le repas, le son est présent sans bidouille.  

-- 
Florentin Duneau

/etc/init.d/alsa-utils ne charge pas la config au boot

[Florentin Duneau]

Bonjour

Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge pas la 
config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils 
et /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La seule solution 
pour récupérer le son est de faire /etc/init.d/alsa-utils start dans une 
console.

Je ne comprends pas pourquoi la config n'est pas chargée lors de l'exécution 
de /etc/rcS.d/S50alsa-utils. Une idée ?  

-- 
Florentin Duneau

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Jean-Luc Coulon (f5ibh)]

Le 01.02.2006 14:32:07, Florentin Duneau a écrit :

Bonjour

Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge
pas la
config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils
et /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La seule
solution
pour récupérer le son est de faire /etc/init.d/alsa-utils start dans
une
console.

Je ne comprends pas pourquoi la config n'est pas chargée lors de
l'exécution
de /etc/rcS.d/S50alsa-utils. Une idée ?


Sans doute y a-t-il un message (voir dmesg, bootlog ou syslog) qui  
contient une amorce d'explicaiton.




--
Florentin Duneau


Jean-Luc


pgpotmtExWtmz.pgp
Description: PGP signature

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Florentin Duneau]

Le Mercredi 1 Février 2006 14:35, Jean-Luc Coulon (f5ibh) a écrit :

 Sans doute y a-t-il un message (voir dmesg, bootlog ou syslog) qui
 contient une amorce d'explicaiton.

 Jean-Luc

Non, rien de rien dans syslog, dmesg et bootlog. Je n'ai pas la ligne Setting 
Up Alsa...  dans bootlog, j'en suppose que le script n'est pas exécuté car 
il n'y pas de messages d'erreurs non plus. 
-- 
Florentin Duneau

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Florentin Duneau]

Voici le bootlog

 .
 null symbol found
 Setting parameters of disc
 Will now activate swap.
 swapon on /dev/hda2
 Done activating swap.
 Will now check root file system.
 fsck 1.39-WIP (31-Dec-2005)
 [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -C0 /dev/hda3
 / has been mounted 30 times without being checked, check forced.
 \002/
 Done checking root file system.
 A log will be saved in /var/log/fsck/checkroot if that location is writable.
 Setting the system clock..
 System Clock set. Local time
 Cleaning up ifupdown...done.
 Calculating module dependencies...done.
 Loading modules...
 ide-cd
 ide-disk
 ide-generic
 psmouse
 All modules loaded.
 Setting the system clock again..
 System Clock set. Local time
 Will now check all file systems.
 fsck 1.39-WIP (31-Dec-2005)
 Checking all file systems.
 [/sbin/fsck.ext3 (1) -- /home] fsck.ext3 -a -C0 /dev/hda7
 /home has been mounted 30 times without being checked, check forced.
 \002/home
 [/sbin/fsck.ext3 (1) -- /var] fsck.ext3 -a -C0 /dev/hda6
 /var has been mounted 30 times without being checked, check forced.
 \002/var
 Done checking file systems.
 A log is being saved in /var/log/fsck/checkfs if that location is writable.
 Setting kernel variables ...
 ... done.
 Will now mount local filesystems.
 mount
 /dev/hda7 on /home type ext3 (rw)
 /dev/hda6 on /var type ext3 (rw)
 Done mounting local filesystems.
 Activating swapfile swap...done.
 Detecting hardware...Discovered hardware for these modules
 ^[[33m*^[[39;49m Skipping already loaded module via_ircc.
 ^[[33m*^[[39;49m Skipping already loaded module via_rhine.
 ^[[33m*^[[39;49m Skipping already loaded module via82cxxx.
 ^[[33m*^[[39;49m via82cxxx_audio disabled in configuration.
 ^[[33m*^[[39;49m Skipping already loaded module uhci_hcd.
 ^[[33m*^[[39;49m Skipping already loaded module ehci_hcd.
 Cleaning /tmp...done.
 Cleaning /var/run...done.
 Cleaning /var/lock...done.
 Running 0dns-down to make sure resolv.conf is ok...done.
 Setting up networking...done.
 Setting hostname to 'bucemcello'...done.
 ^[[33m*^[[39;49m /etc/network/options is deprecated.
 Setting up IP spoofing protection...done (rp_filter).
 Configuring network interfaces...Internet Software Consortium DHCP Client 
2.0pl5
 Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
 All rights reserved.

 Please contribute if you find this software useful.
 For info, please visit http

 Listening on LPF/eth0/00
 Sending on   LPF/eth0/00
 Sending on   Socket/fallback/fallback-net
 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
 DHCPOFFER from 192.168.0.1
 DHCPREQUEST on eth0 to 255.255.255.255 port 67
 DHCPACK from 192.168.0.1
 bound to 192.168.0.4 -- renewal in 43200 seconds.
 done.
 ^[]RSetting up general console font...  done.
 Setting up per-VC ACM's
 ^[[9;30]^[[14;30]Setting up ALSA...done.
 Running ntpdate to synchronize clock.
 Initializing random number generator...done.
 Recovering nvi editor sessions... done.
 Setting up X server socket directory /tmp/.X11-unix...done.
 Setting up ICE socket directory /tmp/.ICE-unix...done.
 INIT
 Starting system log daemon
 Starting kernel log daemon
 Loading ACPI modules
 battery
 ac
 processor
 button
 fan
 thermal
 Starting Advanced Configuration and Power Interface daemon
 Starting Common Unix Printing System
 Starting system message bus
 Starting Hardware abstraction layer
 Starting Avahi mDNS/DNS-SD Daemon
 Starting MTA
 Starting internet superserver
 Starting resource manager daemon
 Starting anac(h)ronistic cron

Je ne sais pas lire car le script alsa-utils est bien exécuté. Par contre je 
suis toujours obligé de l'exécuter une fois logué pour avoir le son.
-- 
Florentin Duneau

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Jean-Luc Coulon (f5ibh)]

Le 01.02.2006 16:07:29, Florentin Duneau a écrit :




 DHCPREQUEST on eth0 to 255.255.255.255 port 67
 DHCPACK from 192.168.0.1
 bound to 192.168.0.4 -- renewal in 43200 seconds.
 done.
 ^[]RSetting up general console font...  done.
 Setting up per-VC ACM's
 ^[[9;30]^[[14;30]Setting up ALSA...done.


Bon, il a fait quelque chose là.
Est-ce que vous avez quelque chose de particulier dans
/etc/default/alsa  ?

Quels sont les modules chargés avant de relancer le tout à la main ?

Jean-Luc


pgpKA5nuJ6w4u.pgp
Description: PGP signature

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Florentin Duneau]

Le Mercredi 1 Février 2006 16:16, Jean-Luc Coulon (f5ibh) a écrit :
 Le 01.02.2006 16:07:29, Florentin Duneau a écrit :

 

   DHCPREQUEST on eth0 to 255.255.255.255 port 67
   DHCPACK from 192.168.0.1
   bound to 192.168.0.4 -- renewal in 43200 seconds.
   done.
   ^[]RSetting up general console font...  done.
   Setting up per-VC ACM's
   ^[[9;30]^[[14;30]Setting up ALSA...done.

 Bon, il a fait quelque chose là.
 Est-ce que vous avez quelque chose de particulier dans
 /etc/default/alsa  ?


Rien de particulier (fichier par défaut) :

# Configuration file for alsa-base

# List, separated by spaces, the names of modules that should be
# unloaded, if present, before the machine is suspended. Use the
# special name all if you would like all ALSA sound modules to be
# removed. The modules that are removed will be loaded again after
# resume.  Currently this only has an effect if you are using apmd.
# Examples:
# Value Action at suspend time
# Do nothing
# snd-cs46xx  Stop sound processes and remove the snd-cs46xx module
# all Stop sound processes and remove all ALSA modules
force_unload_modules_before_suspend=


 Quels sont les modules chargés avant de relancer le tout à la main ?


lsmod avant /etc/init.d/alsa-utils restart :

Module  Size  Used by
appletalk  32752  2 
ax25   49816  2 
ipx25452  2 
radeon 97120  1 
drm64724  2 radeon
lp 10628  0 
button  6544  0 
ac  4740  0 
battery 9476  0 
ipv6  222912  8 
snd_seq_dummy   3652  0 
snd_seq_oss28992  0 
snd_seq_midi8480  0 
snd_seq_midi_event  6592  2 snd_seq_oss,snd_seq_midi
snd_seq44752  6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
i2c_viapro  8020  0 
i2c_core   19408  1 i2c_viapro
yealink11648  0 
psmouse32516  0 
serio_raw   6596  0 
analog 10400  0 
joydev  8960  0 
evdev   8896  0 
via_ircc   23252  0 
parport_pc 32324  1 
snd_via82xx25816  0 
gameport   14024  2 analog,snd_via82xx
pcspkr  1732  0 
parport31880  2 lp,parport_pc
mousedev   10592  1 
irda  162876  1 via_ircc
crc_ccitt   2048  1 irda
floppy 54916  0 
snd_ac97_codec 82528  1 snd_via82xx
snd_ac97_bus2112  1 snd_ac97_codec
snd_pcm_oss46112  0 
snd_mixer_oss  16576  1 snd_pcm_oss
snd_pcm77704  3 snd_via82xx,snd_ac97_codec,snd_pcm_oss
snd_timer  21444  2 snd_seq,snd_pcm
snd_page_alloc  9992  2 snd_via82xx,snd_pcm
snd_mpu401_uart 6656  1 snd_via82xx
snd_rawmidi22688  2 snd_seq_midi,snd_mpu401_uart
snd_seq_device  8012  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq,snd_rawmidi
snd48740  11 snd_seq_oss,snd_seq,snd_via82xx,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device
soundcore   8992  1 snd
rtc11508  0 
via_agp 9344  1 
agpgart31496  2 drm,via_agp
shpchp 39872  0 
pci_hotplug24884  1 shpchp
ext3  118664  3 
jbd48724  1 ext3
mbcache 8516  1 ext3
ide_cd 36996  0 
cdrom  33568  1 ide_cd
ide_disk   15936  5 
ide_generic 1216  0 [permanent]
usbhid 32608  0 
ehci_hcd   29064  0 
via82cxxx   8260  0 [permanent]
via_rhine  21124  0 
mii 5248  1 via_rhine
generic 4356  0 [permanent]
ide_core  112928  5 ide_cd,ide_disk,ide_generic,via82cxxx,generic
uhci_hcd   28304  0 
usbcore   113924  5 yealink,usbhid,ehci_hcd,uhci_hcd
thermal13512  0 
processor  22976  1 thermal
fan 4676  0 

lsmod apres :

Module  Size  Used by
appletalk  32752  2 
ax25   49816  2 
ipx25452  2 
radeon 97120  1 
drm64724  2 radeon
lp 10628  0 
button  6544  0 
ac  4740  0 
battery 9476  0 
ipv6  222912  8 
snd_seq_dummy   3652  0 
snd_seq_oss28992  0 
snd_seq_midi8480  0 
snd_seq_midi_event  6592  2 snd_seq_oss,snd_seq_midi
snd_seq44752  6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
i2c_viapro  8020  0 
i2c_core   19408  1 i2c_viapro
yealink11648  0

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Frédéric Bothamy]

* Florentin Duneau [EMAIL PROTECTED] [2006-02-01 17:14] :
 Le Mercredi 1 Février 2006 16:16, Jean-Luc Coulon (f5ibh) a écrit :
  Le 01.02.2006 16:07:29, Florentin Duneau a écrit :
 
  
 
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.4 -- renewal in 43200 seconds.
done.
^[]RSetting up general console font...  done.
Setting up per-VC ACM's
^[[9;30]^[[14;30]Setting up ALSA...done.
 
  Bon, il a fait quelque chose là.
  Est-ce que vous avez quelque chose de particulier dans
  /etc/default/alsa  ?
 
 
 Rien de particulier (fichier par défaut) :

Qu'as-tu dans /var/lib/alsa/asound.state ? Est-ce que les infos fournies
dans le fichier /usr/share/doc/alsa-utils/README.Debian te donnent un
indice sur ce qui se passe ?


Fred

-- 
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/Writing/SmartQuestionsFr
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[pascal]

Florentin Duneau a écrit :

Bonjour

Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge pas la 
config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils 
et /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La seule solution 
pour récupérer le son est de faire /etc/init.d/alsa-utils start dans une 
console.


Je ne comprends pas pourquoi la config n'est pas chargée lors de l'exécution 
de /etc/rcS.d/S50alsa-utils. Une idée ?  


Je ne connais pas la solution ...
Juste pour signaler que cela fait plusieurs fils que je vois passer sur 
ce même pb et que j'en suis également victime depuis ma dernière mise à 
jour (sous etch) : obligé de relancer alsaconf à chaque démarrage, sinon 
pas de son et la commande alsactl store reste absolument sans effet...

Mes 2 €
Pascal
--
Haut par-dessus leur tête voguaient les blanches sculptures
des nuages, comme en la cervelle de Michel-Ange des volutes
de concept.
M. Lowry



--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Florentin Duneau]

Le Mercredi 1 Février 2006 17:33, Frédéric Bothamy a écrit :
 * Florentin Duneau [EMAIL PROTECTED] [2006-02-01 17:14] :
  Le Mercredi 1 Février 2006 16:16, Jean-Luc Coulon (f5ibh) a écrit :
   Le 01.02.2006 16:07:29, Florentin Duneau a écrit :
  
   
  
 DHCPREQUEST on eth0 to 255.255.255.255 port 67
 DHCPACK from 192.168.0.1
 bound to 192.168.0.4 -- renewal in 43200 seconds.
 done.
 ^[]RSetting up general console font...  done.
 Setting up per-VC ACM's
 ^[[9;30]^[[14;30]Setting up ALSA...done.
  
   Bon, il a fait quelque chose là.
   Est-ce que vous avez quelque chose de particulier dans
   /etc/default/alsa  ?
 
  Rien de particulier (fichier par défaut) :

 Qu'as-tu dans /var/lib/alsa/asound.state ? Est-ce que les infos fournies
 dans le fichier /usr/share/doc/alsa-utils/README.Debian te donnent un
 indice sur ce qui se passe ?


Si je fais alsactl restore après m'être logué, le son apparait. Donc 
asound.state doit être correct (il est bien sauvé lors du reboot..). 
README.Debian ne fournit pas de piste à la correction de ce problème.

-- 
Florentin Duneau

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Vincent Danjean]

Florentin Duneau wrote:

Bonjour

Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge pas la 
config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils 
et /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La seule solution 
pour récupérer le son est de faire /etc/init.d/alsa-utils start dans une 
console.


Je ne comprends pas pourquoi la config n'est pas chargée lors de l'exécution 
de /etc/rcS.d/S50alsa-utils. Une idée ? 


Dans ces cas là, je boote avec le paramètre supplémentaire
init=/bin/sh, puis je lance tous les scripts de démarrage à la main
dans l'ordre :
/etc/rcS.d/01...  start
/etc/rcS.d/05...  start
...
jusqu'à arriver à celui qui me pose problème.

Là, bash -x /etc/rcS.d/xx... start peut aider (ou toute autre
technique pour regarder précisément ce qui se passe dans l'environnement
de boot)

  A+
Vincent


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Thierry B]

Vincent Danjean a écrit :
 Florentin Duneau wrote:
 Bonjour

 Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge
 pas la config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils et
 /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La seule
 solution pour récupérer le son est de faire /etc/init.d/alsa-utils
 start dans une console.

 Je ne comprends pas pourquoi la config n'est pas chargée lors de
 l'exécution de /etc/rcS.d/S50alsa-utils. Une idée ? 
 
 Dans ces cas là, je boote avec le paramètre supplémentaire
 init=/bin/sh, puis je lance tous les scripts de démarrage à la main
 dans l'ordre :
 /etc/rcS.d/01...  start
 /etc/rcS.d/05...  start
 ...
 jusqu'à arriver à celui qui me pose problème.
 
 Là, bash -x /etc/rcS.d/xx... start peut aider (ou toute autre
 technique pour regarder précisément ce qui se passe dans l'environnement
 de boot)
 
   A+
 Vincent
 
 

Je pense que si c'est un problème commun à bcp de monde, il est plus
sage d'attendre que le problème soit corrigé lors d'un prochaine mise à
jour des paquets alsa, plutot que de trop bisouiller, ou alors, vaut
mieux sauvegarder vos fichies avant une modif manuelle lol.

Je rappelle, qu'il y a apt-listbugs, qui est pas mal pour voir les bugs
à l'avance sur des paquets, avant de les installer :-)

Bonne chance :-)

A+


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/init.d/alsa-utils ne charge pas la config au boot

[Vincent Danjean]

Thierry B wrote:

Vincent Danjean a écrit :


Florentin Duneau wrote:


[...]

Je ne comprends pas pourquoi la config n'est pas chargée lors de
l'exécution de /etc/rcS.d/S50alsa-utils. Une idée ? 


Dans ces cas là, je boote avec le paramètre supplémentaire
init=/bin/sh, puis je lance tous les scripts de démarrage à la main

[...]

Je pense que si c'est un problème commun à bcp de monde, il est plus
sage d'attendre que le problème soit corrigé lors d'un prochaine mise à
jour des paquets alsa, plutot que de trop bisouiller, ou alors, vaut
mieux sauvegarder vos fichies avant une modif manuelle lol.


Je ne sais pas si le problème initial est commun ou pas. Ce que
j'exposais est une méthode pour résoudre des problèmes dans les scripts
de démarrage. Personnellement, je n'ai aucun problème avec alsa en ce
moment.


Je rappelle, qu'il y a apt-listbugs, qui est pas mal pour voir les bugs
à l'avance sur des paquets, avant de les installer :-)


Oui, mais une fois installé (avant le rapport de bug par exemple), c'est
mieux d'investiguer le problème pour faire un bugreport avec patch ;-)
Et c'est là où ces techniques sont utiles.

Mais c'est certain que le premier reflexe est d'aller voir dans le BTS
si le problème n'a pas déjà été signalé (avec éventuellement une
correction en attendant le paquet qui corrigera le bug)

  A+
Vincent


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

/etc/init.d

[dédé le homard]

bonjour,

peut on lancer un script par /etc/init.d/...  ,mais en utilisateur normal, et 
non en root ?

et surtout, je voudrais lancer le démon giftd sur un terminal , en plus de la 
session x( par exemple sur le terminal 4, ctrl-alt-f4 ) automatiquement au 
démarage du système, est ce possible ?

j'ai essayé : /usr/bin/giftd | /dev/tty4 dans un script, mais ça n'a pas 
fonctionné 


merci tout le monde,
bonne journée.

Re: /etc/init.d

[Laurent]

Le Jeudi 11 Septembre 2003 21:53, dédé le homard a écrit :
 bonjour,

 peut on lancer un script par /etc/init.d/...  ,mais en utilisateur normal,
 et non en root ?


Je ne pense qu'il y ait d'impossibilité de ce coté là.

 et surtout, je voudrais lancer le démon giftd sur un terminal , en plus de
 la session x( par exemple sur le terminal 4, ctrl-alt-f4 ) automatiquement
 au démarage du système, est ce possible ?

 j'ai essayé : /usr/bin/giftd | /dev/tty4 dans un script, mais ça n'a pas
 fonctionné


T'as les droits d'écriture sur /dev/tty4 ?


 merci tout le monde,
 bonne journée.

Toi aussi


-- 
Laurent
---
Mon site : http://www.monptilinux.fr.st
Designed only with free softwares.

Re: /etc/init.d

[Charles Plessy]

On Thu, Sep 11, 2003 at 05:53:48PM -0200, dédé le homard wrote:
 bonjour,
 
 peut on lancer un script par /etc/init.d/...  ,mais en utilisateur normal, et 
 non en root ?
 

Il y a eu à ce sujet un thread que je n'ai pas lu, sur -devel.

http://lists.debian.org/debian-devel/2003/debian-devel-200308/thrd5.html#03466

-- 
Charles

Re: /etc/init.d

[Frédérick Amorison]

Le jeu 11/09/2003 à 21:53, dédé le homard a écrit :

Tu vis dans le futur!

 bonjour,
 
 peut on lancer un script par /etc/init.d/...  ,mais en utilisateur normal, et 
 non en root ?

Oui si tu l'utilisateur a les droits nécessaires pour accéder aux
ressources.

 
 et surtout, je voudrais lancer le démon giftd sur un terminal , en plus de la 
 session x( par exemple sur le terminal 4, ctrl-alt-f4 ) automatiquement au 
 démarage du système, est ce possible ?
 
 j'ai essayé : /usr/bin/giftd | /dev/tty4 dans un script, mais ça n'a pas 
 fonctionné 

là je ne peux pas t'aider.



 bonne journée.
Bonne soirée :-)

Re: /etc/init.d

[dédé le homard]

Le Jeudi 11 Septembre 2003 14:22, Laurent a écrit :
 Le Jeudi 11 Septembre 2003 21:53, dédé le homard a écrit :
  bonjour,
 
 

 T'as les droits d'écriture sur /dev/tty4 ?
oui, j'ai fait adduser christo tty ( utilisateur christo) et j'ai donné les 
droits d'acces à tty4 à christo, pourtant quand on lance la commande 
/usr/bin/giFTcurs | tty4, la reponse est : permission non accordée ( depuis 
un terminal root)


  merci tout le monde,
  bonne journée.

 Toi aussi

Re: /etc/init.d

[Laurent]

Si c'est pas les droits d'accès à /dev/tty4, ça doit être les droits d'accès 
au binaire 

Là comme ça je vois que ça !

-- 
Laurent
---
Mon site : http://www.monptilinux.fr.st
Designed only with free softwares.

Re: /etc/init.d

[Yannick Roehlly]

dédé le homard [EMAIL PROTECTED] writes:

 bonjour,

 peut on lancer un script par /etc/init.d/...  ,mais en utilisateur normal, et 
 non en root ?

Ta question est-elle « Peut-on lancer un daemon au démarrage en temps
qu'utilisateur normal ? ».

Dans ce cas, il y a un article dans la DWN du 2 septembre. Il semble
que cela soit faisable avec une ligne @reboot dans le crontab normal.

Yannick

Re: /etc/init.d

[Julien Motch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

dédé le homard wrote:
| bonjour,
|
| peut on lancer un script par /etc/init.d/...  ,mais en utilisateur
normal, et
| non en root ?
|
| et surtout, je voudrais lancer le démon giftd sur un terminal , en
plus de la
| session x( par exemple sur le terminal 4, ctrl-alt-f4 )
automatiquement au
| démarage du système, est ce possible ?
|
| j'ai essayé : /usr/bin/giftd | /dev/tty4 dans un script, mais ça n'a pas
| fonctionné
|
|
| merci tout le monde,
| bonne journée.
|
|

Il te suffit d'utiliser la commande start-stop-daemon avec l'option
- --chuid username. Tu peux aussi spécifier le groupe en ajoutant
:groupname acollé à username.

Julien
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/YPxSEW8msFzBCjwRAiKZAJ9ejniBr4pKy9+ro2YBWyZEaUDDJwCeMzPZ
U1+f71ERoBktvvWS6NxCT+U=
=NHlt
-END PGP SIGNATURE-

cron /etc/init.d/mountnfs.sh et start-stop-daemon

[Georges Mariano]

re-Bonjour, 

Voilà, il arrive (assez rarement) que certains services tombent.
Bien souvent il suffit de relancer (stop/start) pour régler le problème.

Comme (ici) on peut se permettre de relancer systématiquement certains
services, je me suis dis, plaçons ça dans un cron histoire d'augmenter
la probabilité de récupérer un service sans intervention humaine (des
fois, on ne s'aperçoit même pas que le service est tombé, mais quand on
le remarque c'est quand y'a personne pour le relancer, loi de Murphy).

Donc, voilà, première expérience :
 30 * * * * root /etc/init.d/mountnfs.sh

Comme prévu, ça marche pô tout à fait du 1er coups ;-)

Starting portmapper... /etc/init.d/mountnfs.sh: start-stop-daemon:
command not found Mounting remote filesystems...

Or, dpkg -S start-stop-daemon
dpkg: /sbin/start-stop-daemon

deux/trois questions :
0) certains services bénéficieraient, il me semble, de ce genre de
traitement (en tout cas c'est l'expérience que j'en ai ;-), genre sympa,
wwsympa, mysqld, ... qui, après des problèmes sur une (autre) machine,
peuvent perdre les pédales. Une grande claque et ça repart...

Est-ce bien raisonnable ?  (le reset pas la claque ... ;-) 

a) est-ce bien (simplement) un problème d'env PATH pour cron ? (/sbin
??)

b) en passant, je suis étonné que /sbin/start-stop-daemon appartiennent
au paquet dpkg; quand je redémarre un daemon je fais de la maintenance
de service pas de paquets ...  ??

je pensais plutôt à un paquet style qqchose-utils...

A+

 


-- 
mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06   
INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59   
BP 317 -- 59666 Villeneuve d'Ascq   
http://www3.inrets.fr/estas/mariano

permissions ds /etc/init.d/

[Philippe Monroux]

Bonjour,

tite question comme ça...:)

Pratiquement toutes les permissions  des fichiers de /etc/init.d/ sont à
755. C'est bon ça au niveau sécurité ?

Et si on les met à 744 est-ce que cela risque de causer des Pbs ?

Phil

-- 
Le savant n'est pas l'homme qui fournit les vraies réponses,
c'est celui qui pose les vraies questions.
C. Lévi-Strauss

Re: permissions ds /etc/init.d/

[deb_dup]

Salut,

Il ne semble pas qu'il y ai de problème.

Pour eviter le lancement de demon, la doc securing-debian-howto, ils disent que 
certain empêchent le lancement des demons avec chmod 644 /etc/init.d/demon. 
Mais, cette méthode n'est pas recommandée. De plus, tu auras un message 
d'erreur au boot, of course.

Jacques


Message d'origine
Date: Fri, 13 Dec 2002 10:58:05 +0400
De: Philippe Monroux [EMAIL PROTECTED]
A: debian-user-french debian-user-french@lists.debian.org
Sujet: permissions ds /etc/init.d/

Bonjour,

tite question comme ça...:)

Pratiquement toutes les permissions  des fichiers de /etc/init.d/ sont à
755. C'est bon ça au niveau sécurité ?

Et si on les met à 744 est-ce que cela risque de causer des Pbs ?

Phil

-- 
Le savant n'est pas l'homme qui fournit les vraies réponses,
c'est celui qui pose les vraies questions.
C. Lévi-Strauss


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: permissions ds /etc/init.d/

[Frédéric Bothamy]

* Philippe Monroux [EMAIL PROTECTED] [2002-12-13 10:58] :
 Bonjour,
 
 tite question comme ça...:)
 
 Pratiquement toutes les permissions  des fichiers de /etc/init.d/ sont à
 755. C'est bon ça au niveau sécurité ?
 
 Et si on les met à 744 est-ce que cela risque de causer des Pbs ?

Je ne pense pas que cela pose de problème. La seule restriction
possible est que si un script fournit un état du processus quand on
lui passe le paramètre status par exemple, les utilisateurs ne
pourront pas l'utiliser. Cependant, la sécurité d'un système ne doit
pas reposer sur ces droits (AMA fragiles), mais bien sur les
permissions d'exécution (fortes) des programmes réellement appelés par
ces scripts (et les permissions sur les périphériques).

Dans le même genre, le script d'initialisation d'aumix pourrait être
appelé par un utilisateur (appartenant au groupe audio) pour rétablir
les volumes de la carte son au niveau par défaut, mais il ne peut pas
les sauver (car il n'a pas les droits sur /etc/aumixrc.

En espérant avoir été assez clair,

Fred

Re: permissions ds /etc/init.d/

[François Boisson]

  Pratiquement toutes les permissions  des fichiers de /etc/init.d/ sont
à
  755. C'est bon ça au niveau sécurité ?
  
  Et si on les met à 744 est-ce que cela risque de causer des Pbs ?

Je ne vois pas ce que cela changerait, il est toujours possible de copier
le script dans un fichier et de modifier les droits du fichier puis de
l'éxécuter.
cp /etc/init.d/toto /tmp
chmod 755 /tmp/toto
/tmp/toto

ou même de faire sh /etc/init.d/toto

En fait, comme le dit Frederic, ce qui est important est la gestion des
droits des pgms appelés par ces scripts.

F.Boisson

 
 Je ne pense pas que cela pose de problème. La seule restriction
 possible est que si un script fournit un état du processus quand on
 lui passe le paramètre status par exemple, les utilisateurs ne
 pourront pas l'utiliser. Cependant, la sécurité d'un système ne doit
 pas reposer sur ces droits (AMA fragiles), mais bien sur les
 permissions d'exécution (fortes) des programmes réellement appelés par
 ces scripts (et les permissions sur les périphériques).
 
 Dans le même genre, le script d'initialisation d'aumix pourrait être
 appelé par un utilisateur (appartenant au groupe audio) pour rétablir
 les volumes de la carte son au niveau par défaut, mais il ne peut pas
 les sauver (car il n'a pas les droits sur /etc/aumixrc.
 
 En espérant avoir été assez clair,
 
 Fred
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]
 

Re: /etc/init.d/sendmail start -- erreur !

[Didier Chalm]

On Saturday 23 November 2002 09:14, [EMAIL PROTECTED] wrote:

 Tout ce qu'il y a de plus normal !

Ah bin non ! Tu récupères du 'stable' et du 'woody', c'est bien la même chose 
(pour l'instant...) mais aussi du 'testing', et là, c'est plus pareil ! C'est 
du 'sarge' !
Il serait peut-être bon que tu harmonises tes noms de distrib : 'stable' _OU_ 
'woody' _OU_ 'testing'  :)

-- 
  [EMAIL PROTECTED]   EPSHOM
  Service Informatique   BREST - FRANCE

Re: /etc/init.d/sendmail start -- erreur !

[spetrot]

La version de sendmail est : (8.12.6-7).
Mon sources.list : 

deb http://http.us.debian.org/debian stable main contrib non-free
deb http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free
deb http://security.debian.org stable/updates main contrib non-free

deb http://security.debian.org woody/updates main contrib non-free
deb http://ftp.fr.debian.org/debian/ woody main non-free contrib
deb http://non-us.debian.org/debian-non-US woody/non-US main contrib non-free

deb ftp://ftp.fr.debian.org/debian/ testing main  
deb-src ftp://ftp.fr.debian.org/debian/ testing main  
deb http://non-us.debian.org/debian-non-US testing/non-US main
deb-src http://non-us.debian.org/debian-non-US testing/non-US main

Tout ce qu'il y a de plus normal !

Stéphane


En réponse à Frédéric Bothamy [EMAIL PROTECTED]:

 * [EMAIL PROTECTED] [EMAIL PROTECTED] [2002-11-22 17:23] :
  Bonjour, 
  
  après un apt-get install sendmail et la configuration qui s'en suit,
 woody 
  essaye de démarrer le MTA et j'ai un message d'erreur : 
  
  Starting Mail Transport Agent: sendmail/usr/sbin/sendmail:
 /lib/libc.so.6: 
  version `GLIBC_2.3' not found (required by /usr/sbin/sendmail)
  /usr/sbin/sendmail: /lib/libc.so.6: version `GLIBC_2.3' not found
 (required 
  by /usr/sbin/sendmail)
  
  Or, on en est à la version stable 2.2 pour glibc.
 
 Installer la bonne version de sendmail ? C'est vraiment bizarre,
 d'après packages.debian.org, aucune des versions de sendmail de
 stable/testing/unstable actuelle n'a été compilé avec la libc6 2.3 ...
 
 Tu as quelle version de sendmail et récupéré de quelle source ?
 
 Fred
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact
 [EMAIL PROTECTED]
 
 

/etc/init.d/sendmail start -- erreur !

[spetrot]

Bonjour, 

après un apt-get install sendmail et la configuration qui s'en suit, woody 
essaye de démarrer le MTA et j'ai un message d'erreur : 

Starting Mail Transport Agent: sendmail/usr/sbin/sendmail: /lib/libc.so.6: 
version `GLIBC_2.3' not found (required by /usr/sbin/sendmail)
/usr/sbin/sendmail: /lib/libc.so.6: version `GLIBC_2.3' not found (required 
by /usr/sbin/sendmail)

Or, on en est à la version stable 2.2 pour glibc.

Comment contourner l'obstacle ?

Re: /etc/init.d [was: Re: RE : Question sous Debian : login GDM]

[Nicolas Kowalski]

Christian Marillat [EMAIL PROTECTED] writes:

[...]

 Cependant, imaginons que l'on souhaite temporairement suspendre un
 service ; je dis bien : imaginons.  Le fait de supprimer le script de
 /etc/init.d/ va rendre impossible la réactivation de ce dernier (par
 update-rc.d), sauf réinstallation du paquetage correspondant, non ? Je
 me gourre complètement ? Il existe une autre commande pour le
 réinstaller ce script ?

 Il n'y a aucun moyen de réinstaller le script, étant donné que ce
 fichier est marqué comme un fichier de configuration, dpkg va considérer
 qu'il a été enlevé sciemment (en principe) et ne le remplacera pas.

 Il vaut donc mieux le renommer que l'effacer.

C'est ce que je ferai en cas de besoin, merci. 

L'avantage, comme décrit ailleurs dans la discussion, étant que on
peut ainsi conserver/se_souvenir_de la priorité lors de la
réactivation du service (style S99gdm - s99gdm, et vice-versa).

Merci à tous pour vos lumières.

-- 
Nicolas

/etc/init.d [was: Re: RE : Question sous Debian : login GDM]

[Nicolas Kowalski]

Edi STOJICEVIC [EMAIL PROTECTED] writes:

[...]

 extrait du man :
 REMOVING SCRIPTS
When invoked with the remove option,  update-rc.d  removes
any  links  in  the  /etc/rcrunlevel.d  directories to the
script  /etc/init.d/name.   The  script  must  have   been
deleted  already  -  update-rc.d checks for this.

Diable ! Je ne l'avais pas vu ce paragraphe là...

Cependant, imaginons que l'on souhaite temporairement suspendre un
service ; je dis bien : imaginons.  Le fait de supprimer le script de
/etc/init.d/ va rendre impossible la réactivation de ce dernier (par
update-rc.d), sauf réinstallation du paquetage correspondant, non ? Je
me gourre complètement ? Il existe une autre commande pour le
réinstaller ce script ?

Merci d'éclairer ma pauvre lanterne.

-- 
Nicolas

Re: /etc/init.d [was: Re: RE : Question sous Debian : login GDM]

[yoann]

- a écrit:


From: Nicolas Kowalski [EMAIL PROTECTED]
Date: Thu, 10 Oct 2002 22:25:44 +0200
In-Reply-To: [EMAIL PROTECTED] (Edi STOJICEVIC's
message of Thu, 10 Oct 2002 18:49:16 +0200)
Message-ID: [EMAIL PROTECTED]
Lines: 24
User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Common Lisp,
i386-debian-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM 
version=2.20
X-Spam-Level: 
Resent-Message-ID: [EMAIL PROTECTED]

Resent-From: debian-user-french@lists.debian.org
X-Mailing-List: debian-user-french@lists.debian.org archive/latest/24289
X-Loop: debian-user-french@lists.debian.org
List-Post: mailto:debian-user-french@lists.debian.org
List-Help: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Resent-Date: Thu, 10 Oct 2002 15:25:59 -0500 (CDT)

Edi STOJICEVIC [EMAIL PROTECTED] writes:

[...]

 


extrait du man :
REMOVING SCRIPTS
  When invoked with the remove option,  update-rc.d  removes
  any  links  in  the  /etc/rcrunlevel.d  directories to the
  script  /etc/init.d/name.   The  script  must  have   been
  deleted  already  -  update-rc.d checks for this.
   



Diable ! Je ne l'avais pas vu ce paragraphe là...

Cependant, imaginons que l'on souhaite temporairement suspendre un
service ; je dis bien : imaginons.  Le fait de supprimer le script de
/etc/init.d/ va rendre impossible la réactivation de ce dernier (par
update-rc.d), sauf réinstallation du paquetage correspondant, non ? Je
me gourre complètement ? Il existe une autre commande pour le
réinstaller ce script ?

Merci d'éclairer ma pauvre lanterne.

 


pour supprimer temporairement un service :

update-rc.d -f ton_service remove

et pour le reactiver :

update-rc.d tonpackage default

ou

update-rc.d ton_service start 20 2 3 4 5 . stop 20 0 1 6 .
(dans ce cas la c'est equivalent au cas default mais tu peux changé les 
runlevels ou ton service sera ou ne sera pas lancé)


2 3 4 5 niveau ou ton service sera lancer

0 1 6 niveau ou ton service sera arreté on non actif

le 20 je ne sais pas à quoi il correspond

yoann

RE: /etc/init.d [was: Re: RE : Question sous Debian : login GDM]

[frederic baujard]

Salut,
Desoler de ne pas avoir trop suivis le debat.Pour suspendre 
temporairement
un service
il suffit de changer le nom du lien dans le rc.
ex:
/etc/rc2.d/ (si tu es au level 2)
mv S20exim _S20exim
et voila pareil pour le level 0 et 6 car si tu supprimes le prog dans init.d
ou le renommer
les liens dans le rc du level correspondant le lien fera appel à rien.

 -Message d'origine-
 De : Nicolas Kowalski [mailto:[EMAIL PROTECTED]
 Envoyé : jeudi 10 octobre 2002 22:26
 À : debian-user-french@lists.debian.org
 Objet : /etc/init.d [was: Re: RE : Question sous Debian : login GDM]


 Edi STOJICEVIC [EMAIL PROTECTED] writes:

 [...]

  extrait du man :
  REMOVING SCRIPTS
 When invoked with the remove option,  update-rc.d  removes
 any  links  in  the  /etc/rcrunlevel.d  directories to the
 script  /etc/init.d/name.   The  script  must  have   been
 deleted  already  -  update-rc.d checks for this.

 Diable ! Je ne l'avais pas vu ce paragraphe là...

 Cependant, imaginons que l'on souhaite temporairement suspendre un
 service ; je dis bien : imaginons.  Le fait de supprimer le script de
 /etc/init.d/ va rendre impossible la réactivation de ce dernier (par
 update-rc.d), sauf réinstallation du paquetage correspondant, non ? Je
 me gourre complètement ? Il existe une autre commande pour le
 réinstaller ce script ?

 Merci d'éclairer ma pauvre lanterne.

 --
 Nicolas


 --
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact
 [EMAIL PROTECTED]

Re: /etc/init.d [was: Re: RE : Question sous Debian : login GDM]

[Christian Marillat]

Nicolas Kowalski [EMAIL PROTECTED] writes:

 Edi STOJICEVIC [EMAIL PROTECTED] writes:

 [...]

 extrait du man :
 REMOVING SCRIPTS
When invoked with the remove option,  update-rc.d  removes
any  links  in  the  /etc/rcrunlevel.d  directories to the
script  /etc/init.d/name.   The  script  must  have   been
deleted  already  -  update-rc.d checks for this.

 Diable ! Je ne l'avais pas vu ce paragraphe là...

 Cependant, imaginons que l'on souhaite temporairement suspendre un
 service ; je dis bien : imaginons.  Le fait de supprimer le script de
 /etc/init.d/ va rendre impossible la réactivation de ce dernier (par
 update-rc.d), sauf réinstallation du paquetage correspondant, non ? Je
 me gourre complètement ? Il existe une autre commande pour le
 réinstaller ce script ?

Il n'y a aucun moyen de réinstaller le script, étant donné que ce
fichier est marqué comme un fichier de configuration, dpkg va considérer
qu'il a été enlevé sciemment (en principe) et ne le remplacera pas.

Il vaut donc mieux le renommer que l'effacer.

Christian

Re: /etc/init.d [was: Re: RE : Question sous Debian : login GDM]

[Christophe « CHiPs » PETIT]

Le jeu 10/10/2002 à 22:37, yoann a écrit :
 
 update-rc.d ton_service start 20 2 3 4 5 . stop 20 0 1 6 .
 (dans ce cas la c'est equivalent au cas default mais tu peux changé les 
 runlevels ou ton service sera ou ne sera pas lancé)
 
 2 3 4 5 niveau ou ton service sera lancer
 
 0 1 6 niveau ou ton service sera arreté on non actif
 
 le 20 je ne sais pas à quoi il correspond

le 20 correspond à l'ordre dans lequel sont exécutés les scripts. Par
exemple, il vaut mieux que le réseau ait démarré avant de lancer apache.

Si tu supprime le service avec update-rc.d, tu perds l'ordre (à moins de
le noter, mais on oublie toujours), c'est pourquoi il est préférable de
renommer le script de /etc/init.d/, ou de coller un exit 0 au début,
ou de faire par exemple un faux script :
# cd /etc/init.d/
# mv service service.orig
# echo # !/bin/sh  service
# echo exit 0  service
# chmod +x service
Ensuite, un coup de mv service.orig service ; /etc/init.d/service
start permet de revenir en arrière sans perdre l'ordre.

A ce propos, est-il prévu d'implanter dans Debian le système chkconfig
de la Redhat et autres, qui permet d'indiquer les runlevels et l'ordre
prévus pour un service en mettant un commentaire du type # chkconfig:
2345 80 20 (de mémoire) dans le script ?

-- 
Christophe «CHiPs» PETIT [EMAIL PROTECTED] http://chips.free.fr/
Linux-Nantes: partagez votre savoir http://www.linux-nantes.fr.eu.org/
Debian: When Code Matters More Than Commercials http://www.debian.org/  
[Qui donne au pauvre prete a Dieu. -- Victor Hugo, Les Voix interieures]

[long] /etc/init.d [was: Re: RE : Question sous Debian : login GDM]

[Yannick Roehlly]

 /etc/rc2.d/ (si tu es au level 2)
 mv S20exim _S20exim

Bonjour (enfin Bonne nuit plutôt),

Mon humble contribution :

Plutôt que de renommer le lien (ou de le déplacer dans un
répertoire d'archive ce qui revient au même...), je suis plutôt
d'avis qu'il faut créer un lien pour terminer le processus
(KnnService).

Dans la pratique, ça ne change pas grand'chose puisque qu'au
démarrage init va essayer de tuer un processus qui n'existe pas.

Par contre, si l'on considère que la possibilité d'avoir des
runlevels différents est une facilité pour avoir plusieurs
configuration, cela prend tout son sens.

Le cas de GDM est particulier, prenons apache comme service.
Mettons que je veuille un runlevel 2 sans apache et un runlevel 3
avec apache.

Si je ne fais que supprimer le lien lancement d'apache dans
/etc/rc2.d :

lilo linux (2 sous entendu) = Tout baigne, apache n'est pas
lancé

lilo linux 3 = Tout baigne, apache est lancé

lilo linux 3 puis init 2 = aïe, apache n'est pas arrêté alors
qu'il ne devrait pas tourner en runlevel 2 !

Le problème est de savoir à quel moment arrêter le service (le nn
de Knn). Un jour quelqu'un de la liste m'avait expliquer comment
connaître le meilleur ordre d'arrêt, s'il se reconnaît...

Je pense qu'on peut raisonnablement se fier à l'ordre de
/etc/rc0.d/

La même manip peut-être faite avec update-rc.d en donnant les
runlevel où le service démarre et ceux où il s'arrête comme cela
a déjà été dit dans ce thread^^^oups fuseau.

Penser aussi à faire une sauvegarde des ordres de démarrage avec
par exemple un ls -R /etc/rc*  mes_services.txt par exemple.

Communautairement,

Yannick

-- 
Entre une mauvaise cuisinière et une empoisonneuse il n'y a qu'une
différence d'intention. Pierre Desproges

Re: /etc/init.d [was: Re: RE : Question sous Debian : login GDM]

[Edi STOJICEVIC]

On 10 Oct 2002 23:37:55 +0200
Christophe « CHiPs » PETIT [EMAIL PROTECTED] wrote:

 le 20 correspond à l'ordre dans lequel sont exécutés les scripts. Par
 exemple, il vaut mieux que le réseau ait démarré avant de  lancer apache.

Pour info, les scripts S40 du répertoire /etc/rcS.d/ montent tous les systèmes 
de fichiers et le réseau est disponible (cf. /etc/rcS.d/README)
 
 Si tu supprime le service avec update-rc.d, tu perds l'ordre (à moins  de  
 le noter, mais on oublie toujours), c'est pourquoi il est  
 préférable de
 renommer le script de /etc/init.d/, ou de coller un exit 0 au début,
 ou de faire par exemple un faux script :
 # cd /etc/init.d/
 # mv service service.orig
 # echo # !/bin/sh  service
 # echo exit 0  service
 # chmod +x service
 Ensuite, un coup de mv service.orig service ; /etc/init.d/service
 start permet de revenir en arrière sans perdre l'ordre.
 
 A ce propos, est-il prévu d'implanter dans Debian le système
 chkconfig
 de la Redhat et autres, qui permet d'indiquer les runlevels et l'ordre
 prévus pour un service en mettant un commentaire du type # chkconfig:
 2345 80 20 (de mémoire) dans le script ?

Ca existe deja :

update-rc.d ton_service start 20 2 3 4 5 . stop 20 0 1 6 .
 
@+

-- 
 .''`.   Debian GNU/Linux 3.0 released !   (\___/)
: :'  :Use it ! ;) (='.'=)
`. `~'   http://www.debianworld.org()_()
  `-   

fichier /etc/init.d/functions

[axel]

Bonjour à tous,


J'ai un script de reconnection Adsl (eci) qui fait référence
à un fichier functions que je ne parviens pas à localiser:

extrait du fichier :

# Source function library.
. /etc/init.d/functions
ECI_SRCRIPT=/usr/local/bin/startmodem
LOG_DIR=/var/log
ECI_LOG=$LOG_DIR/eci.log

Y a t'il un équivalent sous Débian? Ou puis je trouver les infos?

Merci de votre aide.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: fichier /etc/init.d/functions

[VALLIET Manu]

Le 30/03/02, axel a ecrit:

 Bonjour à tous,

 J'ai un script de reconnection Adsl (eci) qui fait référence
 à un fichier functions que je ne parviens pas à localiser:

 extrait du fichier :

 # Source function library.
 . /etc/init.d/functions
 ECI_SRCRIPT=/usr/local/bin/startmodem
 LOG_DIR=/var/log
 ECI_LOG=$LOG_DIR/eci.log

 Y a t'il un équivalent sous Débian? Ou puis je trouver les infos?

/etc/init.d/functions, c'est pas du redhat, ça ?
Si oui, ça sert pas à grand chose, si ce n'est des [ok] verts, et lancer
des demons.
Pour debianiser ton script de démarrage, vire le /etc/init.d/functions, et
regarde ce qu'il manque ensuite. Par exemple, si jamais le script fait
appel à daemon pour lancer un démon (du moins, c'est comme ça que fait
redhat dans mes souvenirs) remplace ça par un start-stop-daemon.

Sinon, les autres scripts de démarrage sont bourrés de bons exemples,
suffit d'adapter.

--
Manu


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Woody /etc/init.d/keymap.sh et clavier franais

[Sylvain Sauvage]

Laurent Pichard wrote:
 
 Bonjour,

Salut,

[...] 
 Je crois qu'il faut faire:
ln -s /usr/share/keymaps/i386/azerty/fr-latin0.kmap.gz
/etc/console/boottime.kmap.gz
 
 A mon avis, cela revient au même que de faire:
 #dpkg-reconfigure console-data
 Puis sélectionner:
 Select keymap from arch list
 Azerty
 French
 With Euro (latin15)
 
 Est-ce pareil pour vous ou suis-je un alien solitaire dans l'erreur?;)

C'est comme ça sur la Woody, je crois me souvenir que ça a changé en
cours de route en fait, pendant un changement de version de
console-tools.

Par contre, un `cp' ne serait-il pas plus judicieux qu'un `ln' ?

-- 
   __ __ __   
  |oo|   | Sylvain Sauvage, doctorant [IAD  SMA]   |   |oo|  
  _)|   |   GREYC -- CNRS UMR 6072, Université de Caen |   _)|  
 //  \\  |  |  //  \\ 
(_|  |_) |   http://www.info.unicaen.fr/~sauvage| (_|  |_)
|_\==/_| | mailto:[EMAIL PROTECTED] __| |_\==/_|

Re: Woody /etc/init.d/keymap.sh et clavier français

[Nicolas SABOURET]

Laurent Pichard wrote:
 
 Bonjour,
 
 Je viens de lire: Utiliser et configurer Debian pour le français de 
 [...]
 Mais le Chapitre 3 Configurer l'entrée et la sortie en français n'est pas
 conforme à ma configuration Woody.

Effectivement, il a été rectifié à la va-vite juste avant mon départ, et
j'ai pu constater de nombreuses fautes par rapport à la woody. J'ai un
peu trop rapidement recopié ce que j'avais fait pour la potato.

Je vais mettre en ligne rapidement une nouvelle version (correcte, cette
fois, je l'espère).

- c'est bien keymap.sh (et non keymaps.sh)
- c'est bien boottime.kmap.gz (et non default)

 
 A mon avis, cela revient au même que de faire:
 #dpkg-reconfigure console-data

Tu n'est pas un alien solitaire et tu as raison : si dpkg-reconfigure
n'est pas utilisable pour le clavier dans potato, il l'est dans woody.

Je vais aussi corriger cela dans ma doc (si l'outil existe, pourquoi
tripoter la config à la main, hein, je vous le demande ?)

Pour la partie potato, je vais proposer aussi d'utiliser kbdconfig.
Merci à Michel G. pour sa suggestion.

Merci à toi pour m'avoir signalé ces erreurs graves de mon document.

Nico.
-- 
Nicolas SABOURET
LIMSI-CNRS, BP133, 91403 Orsay, France
http://www.limsi.fr/Individu/nico

Woody /etc/init.d/keymap.sh et clavier franais

[Laurent Pichard]

Bonjour,

Je viens de lire: Utiliser et configurer Debian pour le français de Nicolas 
Sabouret, à l'adresse:
http://m17.limsi.fr/Individu/nico/debian/debian-french.html/index.html

Mais le Chapitre 3 Configurer l'entrée et la sortie en français n'est pas 
conforme à ma configuration Woody.

D'après ce que j'ai compris, Il est expliqué que sous Debian Woody: 
/etc/init.d/keymaps.sh appelle le fichier   
/etc/console-tools/default.kmap.gz

Chez moi, Le fichier s'appelle en réalité keymap.sh (sans s) et il appelle 
/etc/console/boottime.kmap.gz (pas /etc/console-tools/default.kmap.gz)

Voici un extrait de mon /etc/init.d/keymap.sh:

    command -v loadkeys /dev/null 21 || exit 0
    CONFDIR=/etc/console
    CONFFILEROOT=boottime
    EXT=kmap

Donc, au lieu de faire:
   ln -s /usr/share/keymaps/i386/azerty/fr-latin0.kmap.gz
   /etc/console-tools/default.kmap.gz
Je crois qu'il faut faire:
   ln -s /usr/share/keymaps/i386/azerty/fr-latin0.kmap.gz
   /etc/console/boottime.kmap.gz

A mon avis, cela revient au même que de faire: 
#dpkg-reconfigure console-data
Puis sélectionner:
    Select keymap from arch list
    Azerty
    French
    With Euro (latin15)

Est-ce pareil pour vous ou suis-je un alien solitaire dans l'erreur?;)

Merci à Nicolas et à tous ceux qui passent du temps à expliquer comment 
utiliser et configurer Debian en français. 

Laurent

Re: Woody /etc/init.d/keymap.sh et clavier franais

[Michel G .]

Le Samedi 29 Septembre 2001 20:18, Laurent Pichard a écrit :
 Bonjour,

Bonsoir,

 Donc, au lieu de faire:
    ln -s /usr/share/keymaps/i386/azerty/fr-latin0.kmap.gz
    /etc/console-tools/default.kmap.gz
 Je crois qu'il faut faire:
    ln -s /usr/share/keymaps/i386/azerty/fr-latin0.kmap.gz
    /etc/console/boottime.kmap.gz

 A mon avis, cela revient au même que de faire:
 #dpkg-reconfigure console-data
 Puis sélectionner:
     Select keymap from arch list
     Azerty
     French
     With Euro (latin15)

Sur potato, il existe un petit utilitaire kbdconfig qui permet de choir la 
bonne keymap. Le fichier choisi (dans /usr/share/keymaps/i386/azerty/ par 
exemple) est copié dans /etc/consoletool/default.kmap.gz.

Je ne peux pas te dire si un tel utilitaire existe sous Woody, désolé.

-- 
Michel G.