On 26.10.2011 13:07, Juergen Daubert wrote:

On Tue, Oct 25, 2011 at 03:00:15PM +0200, Michal Soltys wrote:

...

Ok, as promised, this is fresh approach to initscripts. Perhaps a few rough edges here and there, but is thoroughly tested (modulo just-a-moment ago minor changes I did)

thanks a lot, that was a expensive work ;)

At a first, coarse sight I like it, but it's rather complicated compared to our current solution. A quick wc shows that we have about quad the lines, not sure whether this might be too complicated for CRUX or not. I'd really like to hear the opinions of the other core/opt maintainers here.

The complication (though it's for the most part just much more corner-case-resilient code) mainly lies in rc.engine/ subdirectory. For example, what previously was just mount <...>, now checks if it is mounted, remounts to sanitize options, etc. Or better example - in rc.engine/all - functions responsible for stopping/starting services will not wait endlessly for broken or unresponsive rc.d script and kill its process group. And there're also some potentially useful prefixes added (start asynchronously, ignore service). Umount configuration is far more roboust as well. ITOW, what was previously done inline - as one or two liners - now calls "fatter" functions doing stuff much more thoroughly. Overall, the layout is: rc.engine/ lib - small helper functions all - common functions across different runlevels ckld - tiny kmsg logger, when normal syslog is not active sysinit, ... - "fat" functions doing what main rc scripts used to do inline rc.hook/ all/ - common hooks, currently post-umount (stage1) only sysinit/, ... - custom stuff configurable (with legacy symlink from /etc - rc.local, etc.) The general idea is to have standard frame (rc.engine + rc.conf knobs) of things that users would not want to change at all ever (meaning, not to block them to do so "because", but because there's no point), while leaving anything not falling into that category in hooks. From rejmerge point of view - rc.hooks/** + rc.conf would be rejected (though personally, I'd - by default - add all rc stuff)

One thing I do not understand is why you move the code to mount the fusectl filesystem to the init system.

I was actually wondering myself (same thing about configfs or debugfs) - leave in udev (if applicable), leave in rc.engine, or perhaps in rc.hooks. I settled for "engine", as it's just simple virtual filesystem one wants mounted once and forget it's there. It will survive along runtime changes, and until the very reboot. And there's rc.conf knob too. So from all the choices, it seemed the most optimal one (I'd guess similar reasoning was on systemd side, though I don't follow its mailing list). Kind of similar to shm / pts / sys / run (soon) / dev / proc and so on, which are mounted once with desirable options and not touched again.

IMO this should be done at the time the kernel module is loaded. Have you seen the rule I've added in udev 174? Adding the rule to the port opt/fuse might be another option as well.

Btw, current version of my rc-ng repo (did few minor shuffles, so it's forced non-ff) have latest commit of how udev can look with those scripts.

Btw, shouldn't we try to add application specific stuff like the one for lvm and mdadm via the corresponding port, a kind of run-control directory with short scripts added by the packages comes to my mind?

I'd rather left that to users. More complex configurations can vary quite a lot, their parts can be stuffed in different places - depending on one's needs. Existing hooks are just an example/headstart.

P.S. unfortunately my time is still very limited at the moment, but I will try to do a first test of rc-ng next week.

Make sure to fetch the last version (and move mkfifo/mktemp/setsid to /bin - if you mount /usr) - I have few small things in mind to add. At some point I'll push rc-ng-run as well, with all the necessary changes around. udevd already complains loudly about lack of /run, and mtab symlink is pretty nice to have. P.S. I started updating pkgmk as well, I can't live without native git support, and few lesser things (such as local directories) ... for a start ;) Maybe add regular crux@ to CC as well ?

On 28.10.2011 09:53, Juergen Daubert wrote:

On Wed, Oct 26, 2011 at 03:17:01PM +0200, Michal Soltys wrote:

[...]

...

...

Btw, shouldn't we try to add application specific stuff like the one for lvm and mdadm via the corresponding port, a kind of run-control directory with short scripts added by the packages comes to my mind?

I'd rather left that to users. More complex configurations can vary quite a lot, their parts can be stuffed in different places - depending on one's needs. Existing hooks are just an example/headstart.

Hmm, sorry, but my point was a different one. The only, or at least biggest, problem I see with our current rc stuff is the missing feature to extend/modify it via our packages.

And that's nothing we can left over to the user, but the packager of the concerned port has to do.

[1] is a good example for such an extension, my idea for a nice solution would be to add code to the init system via the mdadm package and not to hardcode it to rc. Maybe something similar what you can do with udev rules or with cron by adding stuff to the /ect/cron.d directory.

I see the point, though might be hard to keep it flexible. Btw - about mdadm - see at the bottom.

[...]

...

I started updating pkgmk as well, I can't live without native git support, and few lesser things (such as local directories) ... for a start ;)

I don't see why we need native git support in pkgmk. I'd suggest to go the usual way and discuss the problems and ideas first here and start coding after a common decision, not the other way around ;)

Well, I need it to simplify my life, so not like it will go to waste, but to make a point (motivation and so on) *FYI*: Quite a few repos (not only git ones) provide stable branch, or often if not, then de-facto master (regardless of the actual name) branch is what is interesting - as its more current and stable than tarballs (sometimes very outdated, or treated as 2nd rate citizens so to speak). Few examples: bridge utils - not so long ago - 1.5+fixes in repo, 1.4 stalled tarball for over a year (if not more, don't remember exactly) util-linux - nice stable/v2.20 ref amule - official tarball is [almost always] terribly outdated procps-fork - no tarballs at all, but very nice deb+fed+suse fork (and there're literally many tens of patches for procps ...) Or when kernel.org went out of business, git repos quickly moved out to other sites (github, etc.) often without bothering much about release tarballs or other such mundane things. and so on ... I'm adding feature that (+/-, still in progress, but shaping out nicely): - never stores more on the disk than comparable tarball (no history, no tags, no other junk - carefully crafted 1 parentless commit); that also includes recursively all submodules; ITOW a bit of git plumbing (not a lazy wrapper around git clone) - the version is updated only after "download" (if it didn't exist yet), or only forced at user's request - won't go ahead of maintainer's point in time though - the version is yyyy.mm.dd, automatically generated from original ref's timestamp - any remotely defined ref can be used - the particular point in time is kept - the md5sum is recursive ls-tree of particular ref So basically it should be fully compatible with all existing utils. Quick example: name=util-linux version=none source=(git:... git-ref=( [util-linux.git]="stable/v2.20" ) Then we do usual pkgmk stuff, and the above gets updated to: name=util-linux version=2011.12.13 source=(git:... git-ref=( [util-linux.git]="stable/v2.20" ) git-head=( [util-linux.git]=<sha1> ) And that's all. It can be pushed to the repo. When compiled on user's machine, it will never update the version itself or move ahead of maintainer's actual ref (unless forced). Anytime the maintainer decides to update the port (e.g. due to some new commits), it's a matter of forcing version update and repushing.

Don't get me wrong, every help for CRUX is much appreciated, but with our very limited resources we should use them in the most effective and prioritized way, IMHO.

Well, I needed certain stuff which certainly can be useful for a few folks, so why keep it hidden (be it scripts, or pkgmk, or maybe a few other things - though c++ is not my thing, or itow my opinion is somewhat similar to Linus's one ;) (this is not a flamebait, just fyi)).

...

Maybe add regular crux@ to CC as well ?

Why? I think crux-devel is the appropriate place for such discussions.

It certainly is, but I thought about crux users generally being more technically aware ones than those using other distros (so possibility for some good comments/remarks/ideas, and it's not like the userbase is too big). Well, they should be following devel in such case, but you see the point about CC.

[1] http://crux.nu/bugs/index.php?do=details&task_id=747

Regarding this: - initialization for v3.2 is udev only + mdadm.conf's [few new] knobs (unless 64-md rules are reedited or not included, though this is not stellar idea, considering e.g. hot-remove rules); --assembly --scan is even potentially dangerous without --no-degraded (though that depends on user's expectations) - mdmon must not be killed; this one is autostarted (excluding certain corner cases, see below) but careless kill can end with a nasty surprise (D state), or e.g. a resync after reboot (if say reshape on container was in progress, and mdmon was killed a bit too early). Well - all external metadata updates are done by mdmon, so it's a tiny pandora box when it suddenly dies. That's main motivation behind IMMORTALS=(<stuff>) in rc-ng (also: lvm doesn't need ignore-udev knobs, because udevd is also immortal) There're some corner cases scheduled for fix at some point too, see http://www.spinics.net/lists/raid/msg35492.html Btw, in context of lvm - --mknodes is invalid for udev based lvm (stuff will mostly keep working, but scripts will get out of the way on mismatch, so no more /dev/disk/by* symlinks or other udev goodies). It's fixed in rc-ng version.

On Wed, Oct 26, 2011 at 01:07:28PM +0200, Juergen Daubert wrote:

On Tue, Oct 25, 2011 at 03:00:15PM +0200, Michal Soltys wrote:

...

Ok, as promised, this is fresh approach to initscripts. Perhaps a few rough edges here and there, but is thoroughly tested (modulo just-a-moment ago minor changes I did)

thanks a lot, that was a expensive work ;)

Indeed, impressive stuff!

At a first, coarse sight I like it, but it's rather complicated compared to our current solution. A quick wc shows that we have about quad the lines, not sure whether this might be too complicated for CRUX or not. I'd really like to hear the opinions of the other core/opt maintainers here.

I have to say, i started by looking at rc.conf and i was taken back a bit. Granted, most is comments - but it still spanned my entire terminal screen. The beauty with our current rc is that it takes about 5 seconds to figure out exactly how everything works, and i dont want to loose that. I have to confess I've not yet taken time to look in more detail. Hopefully I'll have more time and energy to do that this weekend.

One thing I do not understand is why you move the code to mount the fusectl filesystem to the init system. IMO this should be done at the time the kernel module is loaded. Have you seen the rule I've added in udev 174? Adding the rule to the port opt/fuse might be another option as well.

Btw, shouldn't we try to add application specific stuff like the one for lvm and mdadm via the corresponding port, a kind of run-control directory with short scripts added by the packages comes to my mind?

+1

best regards Juergen

P.S. unfortunately my time is still very limited at the moment, but I will try to do a first test of rc-ng next week.

_______________________________________________ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel

-- Fredrik Rinnestam

On Wed, Oct 26, 2011 at 01:07:28PM +0200, Juergen Daubert wrote: [...]

P.S. unfortunately my time is still very limited at the moment, but I will try to do a first test of rc-ng next week.

as promised I did a quick test of rc-ng today. I've created a package [1] with your work from 2011-10-30 and installed it over the old rc. I adjusted rc.conf did a 'telinit U' and 'init 6' finally. After system restart I got a ro mounted "/" which is on a JFS filesystem. After running fsck and a restart the system came up as expected. Two points to mention: - setting KEYMAP=de-latin1 in rc.conf dosn't work, dunno why but a error message I saw might be related: CRUX: setting terminal blank/poweroff timers CRUX: setting hostname to: "jue" CRUX: updating timezone to: "Europe/Berlin" CRUX: + random seed: done CRUX: Couldn't open /dev/tty1 /dev/tty2 /dev/tty3 /dev/tty4 /dev/tty5 /dev/tty6 CRUX: + virtual consoles: done CRUX: + essential late things: done CRUX: CRUX init completed Manually setting keymap with loadkeys works. - there are 3 udev daemons running, intentionally? Greetings Juergen [1] httpup sync http://jue.li/crux/ports/#rc rc

On Mon, Oct 31, 2011 at 03:54:11PM +0100, Michal Soltys wrote: [...]

As for consoles, there seems to be a small problem in kbd 1.15.3 regarding loadkeys's options (it worked fine in 1.15.2) - neither --console nor -C handle more than 1. Fixup pushed.

Yep, works now. Thanks for the quick fix. Greetings Juergen