Reprise du message précédent :
slackware utilise l'init BSD
 
ubuntu utilise upstart et RHEL également.

 
autant pour moi sur slack
 
RHEL doit passer sous systemd pour la version 7

Quelques informations sur Gnome 3.6 et Systemd : http://archlinux.fr/news/gnome-3-6 [...] temd-aussi

Passage vers systemd effectué en moins de 10min .. Faut dire que je ne me servais plus de rc.conf à part pour les DAEMONS..

Je suis impressionné par Arch, le passage progressif tout en douceur, et puis c'est plus sain pour l'avenir de passer sur un systeme d'init moins exclusif ..

il serait intéressant de savoir si en entreprise le "systemd" est en vogue ou pas,
 
pour des raisons de sécurité/précaution il se peut que les administrateurs soient réticents à passer les serveurs de production en systemd ( pas assez de recul )

 
concernant les démons j'ai remarqué que si on veut spécifier un ordre de lancement ( genre "iptable" doit se lancer avant ou après network ) c'est un peu plus prise de tête que le fichier rc.conf, il faut aller dans chaque fichier ".service" et ajouter une option de lancement "justbefore ou after" ( plus sûr de la syntaxe ) pour dire à systemd de lancer le service qu'après ou avant le lancement d'un autre service,
 
du coup l'ordre logique des démons ne sera pas tout de suite apparent contrairement au fichier rc.conf où l'on pouvait voir dans le texte l'ordre complet des démons, à moins d'utiliser une commande en ligne qui donne l'ordre de lancement des démons ( mais je n'ai pas trouvé la commande )

Il y a un article dédié à systemd dans le dernier GNU/Linux Mag sorti aujourd'hui en kiosque

tu peux donc nous faire un scan de cet article et le poster sur http://hfr-rehost.net/

 
En entreprise on est encore en RHEL 5/Centos 5/Debian 6 alors systemd ça n'est pas pour tout de suite XD

ce qui reste vachement plus récent que windows xp !

 
Perso, je m'amuse pas à modifier le système d'init sur mes serveurs, je prends celui officiellement supporté par la distrib. Donc j'installerai systemd quand ce sera le choix par défaut...

 
Bah c'est encore supporté, et Debian 6 est la version stable courante de Debian, donc je vois pas d'intérêt d'upgrader, surtout quand c'est des config critiques qui font partie d'infra avec un prix à 6 chiffres

Bonsoir,

Ça fait quinze plombes que je me bats avec emacs car il me fait un « ć » à la place d'un « ç » quand je fait « ' + c » (clavier qwerty, layout us intl) (j'ai découvert ce problème car il m'affiche avec pleins de caractères bizarre là où il y est sensé il y avoir des accents un fichier normalement en UTF8) et je viens de me rendre compte que j'ai le même problème avec libreoffice ou ninja ide   . Et j'ai l'impression que c'est depuis mon passage à systemd.

Dans mon vconsole.conf :

Dans mon locale.conf :

Je n'ai pas le problème sous firefox, ni dans le terminal et j'avais us_intl quelque part dans mon rc.conf je crois, ce qui doit correspondre au us-acentos ici mais ça ne concerne que la console, non ? Mon problème vient plutôt de locale.conf pour le coup ?

edit : si je mets LANG="en_US.utf8" ça fonctionne mais j'ai xfce en anglais. J'ai essayé de mettre LANGUAGE et LC_CTYPE en "en_US.utf8" mais ça ne me donne pas le résultat escompté.

https://bbs.archlinux.org/viewtopic.php?pid=1169849
 
Hardwareclock deprecated

 
 
J'ai rencontré le problème il y a assez longtemps (US International vaincra   ), je n'ai pas creusé particulièrement, j'ai opté pour la solution d'habituer mes doigts au Alt Gr + "," (virgule), qui fonctionne aussi et m'a semblé le remplacer.

 
Après avoir trifouiller des fichiers un peu partout sans résultat (le « soucis » vient de GTK apparemment) je me résous aussi à faire ça mais ça ne me plait pas surtout qu'au travail sous Win ça fonctionne partout.

ca y est je suis passé en full systemd, ca marche bien mais j'ai eu le bug sur network manager qui se loadait pas, c'est bon !

est-ce que tu as essayé d'établir un ordre de lancement des daemons ?

ou bien tes services se lancent dans n'importe quel ordre, au bon plaisir de systemd ?

car ce flou aléatoire n'est pas toujours désirable si certains services doivent se lancer avant d'autres ( genre iptables qui peut boguer s'il se lance avant network, la résolution des noms de domaine peut alors planter pour certaines règles d'iptables si le réseau n'a pas été monté avant ), avec rc.conf l'ordre pouvait s'établir de manière simple par l'utilisateur dans le fichier texte,

la solution que j'ai trouvée était de bidouiller chaque fichier .service au niveau d'un paramètre mais c'est moins pratique ( pas de vision d'ensemble )

Non j'ai tout laissé en vrac et ca tourne donc j'ai pas eu le temps de fouiller plus avant

 
Directive after= dans les fichiers services. Je ne vois pas en quoi c'est moins simple.

 
si tu as 20 daemons ça va être difficile d'avoir une vue synthétique de l'ordre de tous les services ( contrairement au fichier rc.conf ), il y a même un risque de faire un truc incohérent/contradictoire dans l'ordre si on s’emmêle les pinceaux dans les fichiers services au niveau des options "after/before", ce n'est pas très secure comme manière de spécifier l'ordre d’exécution d'un daemon, il y a un chainage qui peut être rompu sans le faire exprès,
 
mais il existe peut-être un petit outil permettant d'afficher la liste des daemons dans leur ordre d’exécution actuel,
 
si tous les daemons sont conçus pour être lancés de manière parallélisés sans ordre particulier alors pas de soucis, mais il y a probablement des cas de figures où il serait souhaitable de maitriser l'ordre de lancement, dans un serveur pro où il y a des daemons dédiés à la gestion de facturation/comptabilité systemd pourrait donner des sueurs à un administrateur novice en systemd

L'idée, c'est que les fichiers de lancement soient upstreamés, ce qui commence à être le cas le plus courant et que les dépendances standards (par exemple, network pour les certains trucs réseaux) soient donc renseignées upstream.

Devoir gérer + de 1 ou 2 fichiers de lancement à la main sera totalement exceptionnel. Et systemd est capable de « deviner » certaines dépendances.
Mais oui, le but c'est de lancer le maximum de services en parallèle et de laisser le noyau faire son boulot pour faire attendre les services qui ont besoin d'un truc spécial (cf http://0pointer.de/blog/projects/systemd.html la partie parallelizing socket service)

Bon bah après le desktop, passage du laptop à systemd, comme dans du beurre

Passage de mon desktop en full systemd réussi également.
 
Effectivement le boot est plus rapide, cependant c'est le chargement de KDE qui est long (no SSD inside)
 
(de toute façon je mets systématiquement la machine en suspend au lieu de l'éteindre)
 
Le shutdown est ultra-rapide

franchement systemd est excellent pour un usage ordinaire. peut etre pas pour de l embarque mais sinon c est vraiment simple et efficace, surtout avec arch ou il y a bcp moins de serviced que pour fedora par exemple

je suis en train aussi de passer à systemd mais je bloque sur la configuration du daemon qui s'appelait "network" sous sysvinit,
 
j'utilise une configuration de type "adresse ip fixe", mais apparemment le service network n'existe plus avec systemd, du coup que faire ?
 
il y a bien ce lien :
 
https://wiki.archlinux.org/index.ph [...] et_network
 
mais je ne sais pas si c'est propre comme manière de procéder, ce que je veux c'est une ligne de commande de type :
 
systemctl enable network.service
 
mais ça me répond :
 
Operation failed: No such file or directory
 

 
Oui c'est propre comme syntaxe, autrement utilise netcfg si tu veux un service pour activer/désactiver ton réseau a la volée via systemd (a la place de dhcpcd donc, netcfg permet d'avoir plusieurs profils : un static, un dhcp, entre autres)

j'ai crée manuellement les 2 fichiers network et network.service mais je n'ai plus internet, impossible de faire un ping :

ping www.google.fr
ping: unknown host www.google.fr

ça m’énerve, car le tutoriel ( que ce soit le site fr ou us de archlinux ) semble considerer que la majorité des utilisateurs sont en DHCP alors qu'il existe des gens qui sont en ip fixe

là je suis en "full systemd", ça démarre vite mais l'inconvénient c'est que je n'ai plus le temps de lire les messages de boot, j'ai cru déceler un message en rouge type fail durant le boot mais j'ai pas eu le temps de lire  

le souci c'est que comme le réseau ne fonctionne plus depuis le passage au full systemd alors je ne peux pas installer le paquet netcfg  

#ls /etc/conf.d  
 
et  
 
#ls /etc/systemd/system/
 
donne quoi ?

finalement j'ai trouvé le moyen d'installer netcfg en utilisant une clé USB contenant l'archive de netcfg ( puis utilisation de pacman -U netcfg ),
 
puis j'ai utilisé le profil "ethernet-static" de netcfg et activé le service netcfg@ethernet-static via systemd, j'ai pu retrouver le réseau ensuite  
 

 
pour ls /etc/conf.d :
 
alsa    autofs  dhcpcd      ftpd             gpm       irexec.conf  netcfg   samba    snmpd  svnserve
apache  crond   fluidsynth  git-daemon.conf  iptables  lircd.conf   network  sensord  sshd   syslog-ng
 
pour ls /etc/systemd/system :
 
getty.target.wants     multi-user.target.wants  sysinit.target.wants
local-fs.target.wants  network.service          syslog.service
 
mais j'ai toujours un message "fail" rouge au boot de systemd et je n'ai toujours pas trouvé le moyen de lire cette info, peut-être qu'il faut consulter un log de systemd ?

dans les logs, tu trouvera la réponse (je sais pas comment c'est configuré sous arch essaye dans /var/log)

comme je suis sur une machine virtuelle ( virtualbox ) j'ai pu faire une capture d'écran lors du boot de systemd,
 
le problème venait de netcfg qui était chargé 2 fois, une fois avec le profil "ethernet-static", puis une seconde fois sans profil, c'est pour ça qu'il affichait un message "failed", j'ai donc désactivé le second chargement de netcfg qui était inutile,
 
j'ai corrigé aussi un autre problème lié à cupsd car le fichier socket n'est plus le même lorsqu'on passe à systemd :
 
https://wiki.archlinux.org/index.ph [...] to_Systemd

après le passage à "full systemd" j'ai remarqué que l'arrêt manuel d'apache et de mysql prenait un temps fou en tapant ces commandes, près d'une minute trente d'attente  :

systemctl stop httpd
systemctl stop mysqld

et je n'ai plus les infos "Ok/done" dans la console quand j'arrête ces 2 services, les 2 services s'arrêtent bien mais il n'y a plus d'information

un autre problème: la commande halt n'éteint pas la machine virtuelle, j'ai bien la mention "system halted" mais la machine ne s'éteint pas,
 
la seule solution c'est de faire un :
 
shutdown -h now

je viens de passer mon portable ( vieux de 10 ans ) sous full systemd,

ça semble ok mais j'ai perdu le son, kde ne trouve plus ma carte son integrée, j'ai ce message d'erreur au boot de kde :

est-ce un bug de systemd ?

ça marchait très bien avant la migration,

je peux quand même encore lire du son et j'entends le son des vidéos avec mplayer, c'est juste kde qui croit que ma carte son a été retiré ( l’icône du mixeur audio de kde est remplacé par une icone en forme de page blanche avec la mention "mixeur introuvable" )

J'avais eu un problème similaire, je l'ai résolu en utilisant vlc à la place de gstreamer comme backend (paramètres phonon).

 
tu as utilisé sysvcompat ?

cette manip ne marche pas chez moi, KDE croit toujours que ma carte son integrée a été retirée, alors que si je lance alsamixer je peux voir que tout est ok au niveau pilote et detection de la carte son, je peux régler les curseurs audio avec alsamixer, les utilitaires de test d'alsa ne montrent aucun problème et je peux lire du son avec mplayer ( par contre ça ne marche pas avec vlc ),

est-ce un bug de systemd avec certains vieux PC ? ( le mien date de 2003, un PC portable pentium 4 avec chipset SIS et une carte son SIS7012 de type codec AC97 )

systemd qui empecherait KDE d'acceder à la carte son ( un problème d'autorisation ) ?

j'ai aussi lancé KDE avec un nouveau profil ( en renommant le dossier .kde4 ) mais le problème est toujours présent,

en attendant je suis repassé à initscripts et là le son est revenu, le problème vient donc bien de la migration à systemd qui crée un bug avec kde

oui j'ai installé sysvcompat

Pareil ici. J'ai configuré kde pour faire poweroff...