IRC log of #cubox of Sun 30 Aug 2015. All times are in CEST < Back to index

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