February 2012 - crux-devel

Re: [crux-devel] rc-ng scripts
by Jose V Beneyto 29 Feb '12

29 Feb '12

Hey all, Michael, thanks a lot, your work is too appreciated. This mail, due to my poor English and little time nowadays, probably not cover everything I think, but I've long wanted to send it and should not delay it anymore, so sorry if there is anything that is not well explained or incomplete. I'll try to argue my POV with advantages/disadvantages as better as possible, and if necessary bringing new ideas and proposals. The first thing that comes to my mind is the complexity of the new solution for system initialization files that you have proposed. I think that it's much more complicated than our current one, but I'm always open to new ideas and improvements. I supposse that you worked in this stuff due to solve/optimize issues you found, maybe with lvm/mdadm, but I'm not 100% sure that I got the whole idea, so please correct me if I'm wrong somewhere. Also I noted that ArchLinux has a similar implementation (1) that could be reviewed. *** (about hooks) *** Basically I like user configurable hooks as alternative to rc.local (or complement), and not as an imposition (some hooks are empty files). I'd like to have a minimal rc port, and let people to use as hooks as need it. This would make for rc* init scripts to load only the hooks that were selected by users to use. Personally, I have years managing CRUX systems and I've never needed anything extra apart from a couple of lines in rc.local, as is the case with rc.local/rc.local.conf in OpenBSD systems. Accordingly, I think we might have enough to accommodate all the hooks in a single directory, I like: /etc/rc.conf.d/hooks. Another disadvantage (IMHO) with rc-hooks could be inherited and overlap the config that has established the user. Which brings us back to run rejmerge for all rc-hooks (around 20 hooks maybe?) after each update rc port. That reinforces the idea of having a small rc port. In addition I'd like to review the naming convention. I prefer the one used by ArchLinux (2) which could be housed in the same directory (maybe /etc/rc.conf.d/hooks/) and not lose its meaning: your schema => my proposal --------------------------- multi/early => multi_start sysinit/early => sysinit_start sysinit/late => sysinit_end sysinit/udev-runner1 => sysinit_udev-runner1 sysinit/udev-runner2 => sysinit_udev-runner2 ... Also I found that there are 2 hooks (sysinit/early and sysinit/pre-trigger1) where the second hook is executed immediately after the first one which is meaningless, so in this case both hooks could be merged into one: --- /etc/rc.sysinit --- rc_hook sysinit/early rc_hook sysinit/pre-trigger1 si_udev --- endof /etc/rc.sysinit --- *** (about functions) *** I like most functions you added and/or implemented, new tools from util-linux-ng (like findmnt, etc.) and also new bash syntax and features. Good work!! But why not have all functions in only one file? (maybe /etc/rc.conf.d/functions) So there are about only 30 functions. $ grep 'function .*()' /etc/rc.engine/* | wc -l 30 IMHO code refactoring makes sense when the same function is used from multiple places. If, for example, rc.engine/multi functions are only used from rc.multi script the it makes no sense to separate it into a single file, so the effect would be the same like include only those functions in rc.multi script since no more rc scripts required them. Also I would like to adopt and/or discuss a more consistent naming convention for functions. your schema ----------- rc.engine/all:function __rc_spawner() { rc.engine/all:function rc_srv_start() { rc.engine/lib:function start_kmsg_log() { rc.engine/sysinit:function __si_console() { rc.engine/sysinit:function __si_seed() { rc.engine/sysinit:function si_std() { my proposal ----------- rc_spawner(), rc_srv_start(), kmsg_log_start(), sysinit_console(), sysinit_seed(), sysinit_std(), ... In addition it would be fine to have some functions like start_service(), stop_service() that could be used by services/daemons in /etc/rc.d/* like sshd or others. For example, stop_service() basically could do: stop_service() { local SUCCESS=0 local SERVICE=$1 local PIDFILE=/var/run/$SERVICE.pid #[ $VERBOSE -eq 1 ] && echo -n "Stopping $SERVICE:\t" if [ -f /var/run/$SERVICE.pid ]; then kill $(< /var/run/$SERVICE.pid) if [ $? -ne 0 ]; then SUCCESS=1 rm -f /var/run/$SERVICE.pid fi else killall -q /usr/sbin/$SERVICE # we could use another argument like $BINFILE instead of $SERVICE [ $? -ne 0 ] && SUCCESS=1 fi #if [ $VERBOSE -eq 1 ]; then # if [ $SUCCESS -eq 1 ]; then # echo "[OK]" # else # echo "[FAILED]" # fi #fi } -- note that this is only an idea and of course it could be written better, have global vars like $VERBOSE, etc. *** (lvm/mdadm) *** For what I see, /etc/rc.hooks/sysinit/udev-runner1 is the place where lvm/mdadm lives. Can't be possible to move this stuff to their respective daemons in /etc/rc.d/lvm and /etc/rc.d/mdadm? It could be a clean way and better for boxes where no lvm/mdadm config is required and/or used. *** (miscelaneous) *** Why you added -8 --noclear to inittab? -- c1:2:respawn:/sbin/agetty 38400 tty1 linux ++ c1:2:respawn:/sbin/agetty 38400 -8 --noclear tty1 linux IMHO, I would leave it as is and give users freedom to change or not. Why not move rc.engine/tlkd to functions as tlkd(), or even to /etc/rc.d/tlkd as a complete daemon service? I'm sure I missed something but at least I hope I have expressed my ideas and opinions. Best regards, (1) https://wiki.archlinux.org/index.php/Arch_Boot_Process#.2Fetc.2Frc.sysinit (2) https://wiki.archlinux.org/index.php/Arch_Boot_Process#Custom_hooks -- Jose V Beneyto | http://sepen.it.cx/

1 0

crux ppc project suspended
by acrux 16 Feb '12

16 Feb '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi all, due a lack of working developers, modern hardware and resources after nearly ten years i'm sadly going to suspend the CRUX PPC GNU/Linux project. It's not a full switch off but future updates 'll be discontinued and, anyway, _not_ ensured. all the best, - - --nico - - -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk88RIMACgkQxq34tDeO7Lj/lACeKy8JGgxoug13GFszbcHQ/f0d 1dMAnignY7EXLDWetpvV5R7UTxAYEEcR =Cg29 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk88VPoACgkQxq34tDeO7LgikQCeOlXxeA18oV+xG3H4AN/f29Fe Z/IAn0M4GkAJ6iT6LhjUTlgsYqqTl/ut =yhi2 -----END PGP SIGNATURE-----

1 0

Fw: Re: dhcpcd uses clang if available on the system and it's not always good on linuxppc
by acrux 09 Feb '12

09 Feb '12

hi all, I just received some suggestions from the dhcpcd's author. I guess it could be the right moment to review dhcpcd section in the "Network Configuration" paragraph in CRUX Handbook. --nico Begin forwarded message: Date: Fri, 03 Feb 2012 17:45:35 +0000 From: Roy Marples <roy(a)xxx.name> To: acrux <acrux(a)xxx.it> Subject: Re: dhcpcd uses clang if available on the system and it's not always good on linuxppc On Thu, 2 Feb 2012 12:35:33 +0100, acrux wrote: > [...] (CRUX main project uses dhcpcd as default) I just checked your init script for dhcpcd.... May I make some recommendations? /sbin/dhcpcd -t 10 -h $HOSTNAME eth0 ... /usr/bin/killall -q /sbin/dhcpcd May I recommend this instead? /sbin/dhcpcd -t 10 ... /sbin/dhcpcd -x Firstly, when invoked like that it runs in master mode and handles the situation where you have more than one interface a lot better. Like say a laptop and wired and wireless both connected (and maybe a 4G phone) and dhcpcd will handle routing and DNS correctly, preferring by default wired > wireless > 4G When stopping with -x, the call will spin until dhcpcd has exited, which may or may not be important if the user has defined any hooks that must be called before spinning down the disks. Lastly, is crux using dhcpcd-dbus and dhcpcd-ui(gtk) for a system tray notification of dhcpcd state? Thanks Roy -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/

2 1