10:37 | topi`_ | I need to make my system boot faster. I found that there's a way to get rid of sloppy sleeps when doing a systemd directed startup - other services depend on my script configuring the net etc. |
10:38 | topi`_ | it's quite easy to tell systemd that the script has finished init and is now in its main loop - via a UNIX socket |
10:38 | topi`_ | so if someone is in trouble trying to get systemd booting up as fast as possible, I have some experience :) and actually systemd makes especially the imx6q boot up really really fast from a SSD |
10:39 | topi`_ | I have one quad and several single core HB's |
10:44 | jnettlet | topi`_, you should enable fastboot for u-boot as well. Then u-boot only takes .3 seconds |
10:45 | jnettlet | I will be pushing my driver interface to the new kernel later today. It basically exposes a sysfs node that can be written to, to enable it after a successful boot |
10:47 | jnettlet | topi`_, are you patching every service to get the performance increase? |
18:14 | topi`_ | jnettlet: not really. but our product depends on a custom service that does network stuff, which can delay the overall boot time a lot |
18:15 | topi`_ | you see, I just add a lot of sleep() into the services which depend on that, with a healthy margin so that it always works - but it should really signal when everything is fully set up and not rely on sleeping |
18:18 | jnettlet | topi`_, is the systemd dependency system not working properly for it? |
18:20 | kelly_ | the systemd dependency system works a charm, but there are quite a few .service files that are being used that are not quite right |
18:21 | kelly_ | i've had to replace some commonly distributed service files |
18:22 | kelly_ | also, some of the service files were written early in the systemd cycle, and should be updated |
18:23 | jnettlet | always a problem. unfortunately systemd developers are way too involved in doing things like replacing su for no apparent reason |
18:24 | kelly_ | heh, yeah that one has me scratchin my head too |
18:25 | jnettlet | adding yet another codebase to monitor for exploits of that manner doesn't make much sense to me. However they also want to move the virtual console to userspace which is a possible exploit on its own |
18:29 | jnettlet | blah...yocto is making my brain melt |
18:30 | jnettlet | topi`_, you have had some problems with gigabit ethernet between your switch and the HB right? |
18:31 | kelly_ | one thing that i've done for a couple of daemon's that depend on a particular /dev/??? or something of that nature, is early in main() i just put a test for the existince of the /dev/??? and just delay up to a certain time for it to become available, if it doesn't show up then i error out |
18:31 | jnettlet | kelly_, you can actually write udev rules that trigger systemd services once the device becomes available |
18:31 | jnettlet | we have had to do that for our bluetooth userspace firmware patching. |
18:33 | jnettlet | I know many linux purists hate the thought, but I am really excited for kdbus to finally make it into the kernel and fix a lot of these problems |
18:33 | kelly_ | yeah, in this case udev trigger didn't seem like a good fit |
18:33 | kelly_ | yeah, i played with kdbus early...it's taken quite a while for it to actually get into the kernel though |
18:39 | jnettlet | well that is unfortunately due to some systemd backlash. |
18:39 | jnettlet | Kay failing to give any consideration to the kernel when the whole systemd debug thing happened set everything back quite a bit |
18:40 | jnettlet | the politics of OSS |
18:42 | kelly_ | jnettlet, i have nftables doing a pretty good job on my firewall now, i did a staged rollout with workstations getting simple nftables configs for quite some months before i put it put it on the firewall |
18:43 | kelly_ | the nftables doc is kinda weak at the moment, but the simple/succinct firewall rules are worth it |
18:44 | jnettlet | I have actually be using firewalld more and am decently impressed. |
18:45 | jnettlet | I need to spend some more time and look at nftables |
18:46 | jnettle | 18:46 * jnettlet is wishing we used still used punch cards because I would love to take bitbake to the bathroom and really express what I think about it. |
18:46 | kelly_ | i was an iptables user for years and years, but recently my firewall setup started mis-behaving, and was just too long to do a good job debugging, so i finally went nftables |
18:48 | kelly_ | the openwrt firewalling (luci) code seems to be pretty simple to manage too for basic stuff |
18:49 | jnettlet | yeah, they do a pretty good job of breaking things into zones |
19:11 | topi`_ | oh, will the kdbus stuff enter the kernel? perhaps I'm too much of a purist, but shouldn't that stuff stay in userland? |
19:11 | topi`_ | the whole dbus is just a hack |
19:19 | jnettlet | topi`_, the roundtrip to userspace every time causes too much latency. |
19:19 | jnettlet | kdbus is not much different than the other socket interfaces that are already in the kernel |