**** BEGIN LOGGING AT Tue Jun 05 03:00:16 2018 Jun 05 03:01:47 that's really weird. can you pastebin the current contents of your /boot/uEnv.txt ? Jun 05 03:06:57 zmatt: yup, it's here: http://paste.debian.net/1028002/ Jun 05 03:07:42 uhh okay that looks fine to me Jun 05 03:10:44 can you check: cat /proc/cmdline Jun 05 03:11:18 to check whether bone_capemgr.uboot_capemgr_enabled is enabled Jun 05 03:12:41 looks like it is Jun 05 03:12:45 "console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait uboot_detected_capes=BB-BONE-4D4R-01, coherent_pool=1M net.ifnames=0 quiet" Jun 05 03:13:00 oh you have an actual cape attached? Jun 05 03:13:12 yeah, it's a display Jun 05 03:13:29 that results in an overlay being loaded for that cape, hence cape-universal is disabled Jun 05 03:13:38 ah. Jun 05 03:13:43 so you'll need to use overlays after all Jun 05 03:13:53 okay, cool Jun 05 03:14:13 I just was poking around sysfs and I see that the pins for UART1 DO have pinmux entries Jun 05 03:14:33 uart1? earlier you said uart2 ? Jun 05 03:14:43 yeah, I wanted uart2 Jun 05 03:14:54 because I thought that's what didn't conflict with my cape Jun 05 03:15:12 but maybe UART1 would work instead Jun 05 03:15:24 it looks like it shouldn't, based on the pin list Jun 05 03:15:50 I don't know why you'd have problems loading the uart2 overlay, it should just work I think Jun 05 03:16:27 also I don't seen a plausible reason why any pins would be muxed to uart1 Jun 05 03:17:00 yeah, the display cape is supposed to use the uart1 pins Jun 05 03:17:15 I'll try the cape method again now that I've wiped the mmc bootloader Jun 05 03:17:17 uart1 conflicts with the lcd cape yes Jun 05 03:17:48 btw if you want an overview of the current pinmux config, you may find my show-pins utility useful: https://github.com/mvduin/bbb-pin-utils/#show-pins Jun 05 03:18:01 probably beats manually digging around in sysfs Jun 05 03:19:43 haha, YES! that's awesome Jun 05 03:20:48 ah! /dev/ttyO2 is back. a promising sign Jun 05 03:21:01 as symlink to /dev/ttyS2 no doubt Jun 05 03:21:08 and yes, the UART is working Jun 05 03:21:18 thank you zmatt! Jun 05 03:21:27 (ttyO* are kinda deprecated, although they still work for backwards compatibility) Jun 05 03:21:55 yeah, I'm actually using ttyS2 in my program since it has the dialout group on it Jun 05 03:22:33 there's obviously no difference in permissions or whatever since ttyO2 is just a symlink to ttyS2 Jun 05 03:22:39 so they're equivalent for all purposes Jun 05 03:22:56 but ttyS2 is the actual name of the device and ttyO2 is just a backwards-compat thing Jun 05 03:23:29 cool. good to know Jun 05 03:24:26 this was driving me crazy since I got the same config working on a different BB. it's really good to know that a flashed old bootloader can cause problems Jun 05 03:25:13 yeah, that was ultimately the root cause of your problems Jun 05 03:25:42 it's probably the #1 issue I see here Jun 05 03:25:45 currently Jun 05 03:27:23 I bet. It's so sneaky. I had totally even forgotten that I ever flashed anything to the mmc, it was probably like two years ago Jun 05 03:51:01 e Jun 05 07:35:08 hey i need help with my Beaglebone green wireless... Jun 05 07:35:15 any experts here? Jun 05 10:46:45 (there are, but you didn't ask an actual question nor wait for an answer) Jun 05 10:47:24 geoffs: well there's an image flashed to eMMC by default when shipped from the factory Jun 05 11:04:19 Can anyone help me with these error : "bone_capemgr bone_capemgr: Failed to add slot #1" Jun 05 11:04:26 Can anyone help me with these error : "bone_capemgr bone_capemgr: Failed to add slot #1"? Jun 05 11:05:26 what are you trying to do? Jun 05 11:08:11 I'm trying to reduce the boot time in beagle bone black... Jun 05 11:09:02 what distribution/os are you running on the BBB? Jun 05 11:09:26 Debian... Jun 05 11:09:51 which version and which type of image? Jun 05 11:10:21 Debian GNU/Linux 8 Jun 05 11:11:17 do you require a graphical user interface via HDMI? Jun 05 11:11:32 No... Jun 05 11:12:14 then the easiest way to start would be to flash a latest IoT image or if you interface via UART console, then the console image Jun 05 11:12:23 those should boot significantly faster already Jun 05 11:13:10 further significant reduction would likely require a purpose built embedded distribution image Jun 05 11:13:37 Ok, but what this log says? "bone_capemgr bone_capemgr: Failed to add slot #1" Jun 05 11:18:28 is that kernel console? Jun 05 11:18:34 which kernel version? Jun 05 11:25:41 do you have anything plugged into the BBB? Jun 05 11:48:37 Yes, its the kernel console, nothing is plugged in BBB... Jun 05 11:49:33 Linux version 4.4.16 Jun 05 12:39:15 Hello everyone Jun 05 12:39:32 I have a question about the BBB and the BBB wireless Jun 05 12:41:39 I would like to know when connecting it to a accelerator sensor, or any other sensor, if the BBB can send command to the sensor asking for it to sense or to send data Jun 05 12:47:06 HELP Jun 05 12:47:22 I have a question about beagle bone Jun 05 12:47:43 I am connecting it to two different sensors Jun 05 12:48:20 and I would like to know if I can send a command from the BBB to the sensors asking them to collect data or/and send data to the BB Jun 05 12:50:40 zofbot Jun 05 12:52:43 sorry I did not understand you Jun 05 12:53:15 elen_: your question is extremely vague and unclear Jun 05 12:53:50 I am sorry, I will try to clarify Jun 05 12:54:29 I am working with a wireless beagle bone, collecting data from 3 accelerator sensors and 4 strain sensors Jun 05 12:56:18 In order to get the same timestamp in all the measurements I thought of the idea of the beagle bone sending a command periodically to the sensors asking them to collect data Jun 05 12:56:42 I do not know if something like that would be possible that is why I am asking Jun 05 12:56:46 Thank you in advance Jun 05 12:56:48 well that will depend entirely on your sensors Jun 05 12:57:31 So the beagle bone has this ability? Jun 05 12:57:55 this isn't a question about the beaglebone, it's a question about whether your sensors have some way to synchronize their sampling Jun 05 12:58:31 which I don't think is common, but maybe I'm wrong Jun 05 12:58:37 Do you mean all 7 communicating together? Jun 05 12:58:59 I mean e.g. some sync input to trigger a sample Jun 05 13:00:40 But my question was if the beagle bone can somehow control this sync Jun 05 13:01:14 if the sensors have some sort of synchronization input to trigger sampling then you could hook that up to a gpio Jun 05 13:03:23 Thank you for help! Jun 05 13:39:01 Hello. I just bought a new PSU (320W). I've connected it to my bb-x15, but it only boots for like 7 sec before turning off again. Any ideas? (the output is 12V and supports up to 10A) Jun 05 13:40:02 I doubt it's psu-related then. I'm using 12V 1A and even that's working fine Jun 05 13:40:24 there's no indication on the serial console of anything going wrong? Jun 05 13:46:25 No, no indication Jun 05 13:46:41 I've tried the same beagle with other PSU's, and it works fine Jun 05 13:47:09 oh, huh, well then evidently the psu *is* the problem :) Jun 05 13:57:38 Hi I'm trying to use mt7601u usb wifi adapter on debian buster withut success: Jun 05 13:58:04 dmesg: Jun 05 13:58:05 [ 22.365018] mt7601u 1-1:1.0: ASIC revision: 76010001 MAC revision: 76010500 Jun 05 13:58:05 [ 22.374838] mt7601u 1-1:1.0: Direct firmware load for mt7601u.bin failed with error -2 Jun 05 13:58:05 [ 22.375482] mt7601u: probe of 1-1:1.0 failed with error -2 Jun 05 13:58:05 [ 22.385080] usbcore: registered new interface driver mt7601u Jun 05 13:58:23 lsmod: Jun 05 13:58:25 Module Size Used by Jun 05 13:58:25 mt7601u 95394 0 Jun 05 13:58:25 mac80211 690472 1 mt7601u Jun 05 13:58:25 cfg80211 589989 2 mac80211,mt7601u Jun 05 13:59:11 interfaces: Jun 05 13:59:13 allow-hotplug wlan0 Jun 05 13:59:13 iface wlan0 inet dhcp Jun 05 13:59:25 what can I check ? Jun 05 14:02:58 well evidently it's missing a firmware file Jun 05 14:03:24 it's trying to load /lib/firmware/mt7601u.bin Jun 05 14:04:07 which google tells me is part of debian package "firmware-misc-nonfree" Jun 05 14:14:18 hmmm autosleep only wakes from a gpio-key on kernel 4.9.88 and not on 4.14.40. Neither seem to wake from autosleep with an RTC alarm. I have a handler in place in my test program that takes a wakelock, does something and then releases the lock, that only works on the gpio-key in that one version of the kernel. Jun 05 14:14:18 zmatt: add another beer to due list......:-)) Jun 05 14:15:02 fred__tv: lol. I don't drink alcohol, but thanks Jun 05 14:27:09 #konversation Jun 05 15:28:47 Invitation Age of sail at #AdventuresofChat Jun 05 15:50:35 anyone experienced in wpa_supplicant ?? Jun 05 15:53:23 buster hasn't it installed, adapter recognized , wlan0 up but no auth to AP Jun 05 15:54:25 after installation I have to force it up and auth manually with "wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf" Jun 05 15:55:50 My other beagle with debian 9 instead, just need to declare ssid and wpa key on /etc/network/interfaces , and all starts and connects at boot Jun 05 15:56:19 why is this ? Jun 05 15:57:22 it sounds like you're just having a weird mess with network managers. I'm pretty sure that when using connman, you're not supposed to mess with wpa_supplicant directly at all Jun 05 15:57:45 conversely, if you want to configure it yourself in a different way, then you shouldn't use connman at the same time Jun 05 15:57:56 ohhhhh... Jun 05 15:58:10 I don't know how wpa_supplicant works together with ifupdown, which you seem to be trying to do? Jun 05 15:58:22 I've only used it in combination with systemd-networkd Jun 05 15:58:52 probably I disabled connman in debian9 .... Jun 05 15:59:56 from what I remember... Jun 05 16:00:32 different network managers have different pros and cons I guess. but you should definitely not use multiple network managers at the same time Jun 05 16:02:08 for some network managers, such as gnome-network-manager and I think also connman, no config file is used for wpa_supplicant at all, instead it's configured via dbus by the network manager Jun 05 16:02:24 i.e. the actual config is done purely in the network manager Jun 05 16:02:59 hmmmm connman not installed in buster neither..... Jun 05 16:04:46 in contrast, systemd-networkd doesn't concern itself with wifi config whatsoever, leaving that entirely to wpa_supplicant (which therefore needs standalone config in that case). once you're associated it proceeds similar to when you'd have link up on ethernet Jun 05 16:05:18 ps ax says wpa_supplicant is running (automatically) in debian9 , but I don't know how it is called at boot.... Jun 05 16:06:31 depends on which service file is enabled Jun 05 16:07:04 I didn't like any of the default ones and wrote my own Jun 05 16:08:08 how can I discover how wpa_supplicant is started and replicate in buster ? Jun 05 16:09:01 systemctl status wpa_supplicant wpa_supplicant@wlan0 Jun 05 16:09:08 exactly one of those two will be running presumably Jun 05 16:10:05 with debian's default service files, the former is purely available via dbus and doesn't bring up any interfaces on its own (suitable for use with connman or gnome network-manager) Jun 05 16:10:57 the latter uses a template to bring up an interface-specific wpa_supplicant with standalone config Jun 05 16:11:12 ● wpa_supplicant.service - WPA supplicant Jun 05 16:11:13 Loaded: loaded (/lib/systemd/system/wpa_supplicant.service; disabled; vendor preset: enabled) Jun 05 16:11:13 Active: inactive (dead) Jun 05 16:11:27 it is running however... Jun 05 16:12:28 I wanted a global dbus-controllable wpa_supplicant with standalone config, hence I made a custom service file ( https://pastebin.com/dT7nBLyE ... I'm also using a custom-compiled wpa_supplicant which is why it's in /usr/local for me) Jun 05 16:12:32 that's odd Jun 05 16:12:44 maybe check with systemd-cgls to what unit it belongs? Jun 05 16:14:20 weird..... it is running also in buster , despite wlan0 is not evenlisted in ifconfig : Jun 05 16:14:46 ● wpa_supplicant.service - WPA supplicant Jun 05 16:14:46 Loaded: loaded (/lib/systemd/system/wpa_supplicant.service; enabled; vendor preset: enabled) Jun 05 16:14:46 Active: active (running) since Tue 2018-06-05 15:45:33 UTC; 28min ago Jun 05 16:14:46 Main PID: 318 (wpa_supplicant) Jun 05 16:14:46 Tasks: 1 (limit: 425) Jun 05 16:14:46 Memory: 2.8M Jun 05 16:14:48 CGroup: /system.slice/wpa_supplicant.service Jun 05 16:14:50 └─318 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant Jun 05 16:14:52 Jun 05 15:45:33 beaglebone systemd[1]: Starting WPA supplicant... Jun 05 16:14:54 Jun 05 15:45:33 beaglebone wpa_supplicant[318]: Successfully initialized wpa_supplicant Jun 05 16:14:56 Jun 05 15:45:33 beaglebone systemd[1]: Started WPA supplicant. Jun 05 16:15:15 *please* don't paste multiline stuff in chat Jun 05 16:15:27 you're right.... Jun 05 16:15:42 and why is that weird? the default distribution is made to work both on wired and wireless beaglebones Jun 05 16:16:38 also, that service is automatically started by dbus activation Jun 05 16:16:50 so presumably that system is using connman? Jun 05 16:16:55 oh never mind Jun 05 16:17:00 it also auto-starts Jun 05 16:17:24 that's really weird, I don't understand why wpa_supplicant.service has WantedBy=multi-user.target Jun 05 16:17:55 since that service doesn't do anything at all until it's configured via dbus, you'd think dbus activation suffices Jun 05 16:18:02 I just don't understand (my fault) why in debian9 I had to do nothing more than install adapter driver and set ssid/key Jun 05 16:18:50 I very much doubt it has anything to do with debian version, and everything to do with overall config Jun 05 16:19:26 at its boot wlan0 comes up and associates to AP Jun 05 16:19:58 no , not debian version but config as you said Jun 05 16:20:20 but a good start would be to choose which network manager you want to use and make sure only that one is enabled Jun 05 16:21:02 how can I know which one is used in working beagle ? Jun 05 16:21:12 connman is the default in bb.org images (and has been for quite a while), so that presumably requires the least effort Jun 05 16:21:36 I'd expect all you have to do there is use connmanctl to configure your wifi ssid/key Jun 05 16:21:57 no, connman is not installed in both Jun 05 16:22:06 ?? Jun 05 16:22:28 I'm 99.9% sure connman is still the default network manager on bb.org images Jun 05 16:22:55 at least the iot images... maybe not the console images? I thought it was, but I'm not sure Jun 05 16:23:23 the first thing I always do is replace whatever network manager is being used by systemd-networkd, so I never really pay much attention to it Jun 05 16:23:45 Reading state information... Done Jun 05 16:23:45 Package 'connman' is not installed Jun 05 16:24:20 ¯\_(ツ)_/¯ well I guess it's not default on console images then Jun 05 16:24:53 probably..... Jun 05 16:25:03 which probably means ifupdown is, which sucks. I've tried using it with wpa_supplicant at some point in the past but I remember it being a horrible mess Jun 05 16:25:06 oops....time to go Jun 05 16:25:07 ifupdown sucks anyway Jun 05 16:25:47 tomorrow , with fresh brain.... Jun 05 16:25:51 Can anyone think why in my /var/log/syslog I have some garbage? Could radio interference cause that? I'm talking about a big block of garbage not apparently attributed to a timestamp or process Jun 05 16:25:57 thank you Jun 05 16:26:10 windsurf_: unclean system reset/poweroff Jun 05 16:27:43 zmatt so our devices sit out in the field operated by others and I got a report that the device stopped displaying what it should on its LCD. We told them to shut it off (which would have been an unclean power-switch off). How can I be sure that the garbage wasn't the cause of the complaint vs the improper shutoff? Jun 05 16:28:09 ultimately I'm looking for what might have caused the original issue (for which you don't have enough information about yet) Jun 05 16:28:38 windsurf_: how many bytes of garbage? Jun 05 16:29:54 and anything is possible of course, but unclear poweroff is a known way to get blocks of garbage in logfiles, and I have trouble imagining other ways you'd get that Jun 05 16:30:33 though note I'm not using rsyslogd at all myself, since it's kinda redundant with systemd-journald Jun 05 16:31:04 (and we don't have logging to eMMC enabled by default since we care about eMMC lifetime) Jun 05 16:37:09 lets see Jun 05 16:37:43 zmatt so the garbage is always a repeat of ^@ which I'll count as one byte Jun 05 16:38:24 here it is https://pastebin.com/GT8jN20f Jun 05 16:38:31 some line breaks in there too Jun 05 16:38:35 yeah that's a nullbyte Jun 05 16:38:43 ah interesting. significance here? Jun 05 16:39:01 of null Jun 05 16:39:07 yes it's a big block of zeroed data Jun 05 16:39:21 because the space was allocated but the actual data never got written out Jun 05 16:39:23 due to power cut Jun 05 16:39:47 emmc == SD card? Jun 05 16:40:00 we don't use sd cards Jun 05 16:40:10 ah that makes sense about unfilled alloc Jun 05 16:40:52 (I wouldn't trust an sd card to maintain proper contact over the device's lifetime in the presence of vibrations during shipping or operation) Jun 05 16:40:55 So I guess I could infer for now that the garbage is the side effect of the user powering off the device rather than the source of what made them want to Jun 05 16:41:01 yes Jun 05 16:41:30 cool, that narrows it down. Jun 05 16:43:37 zmatt hey btw, I think you helped me out with a script to fix the power button to make sure it triggered a halt. I have a SIGINT handler in my main program that the BB runs to quickly change the message on my LCD before it quits. It works if I CTRL-C in an ssh terminal but if I press that button it's too fast and doesn't get a chance to, which makes for strange usability – the screen sometimes renders half an old message. Any pointers on where to Jun 05 16:43:37 slow that down? Should I just study the code some more? Jun 05 16:44:21 also wondering what people do for battery powered devices that need to shut them down in a usable way. Right now our process is to instruct users to first press the tiny BB button, wait a few seconds then power off. It's not ideal Jun 05 16:44:38 (because we're looking for idiot proff) Jun 05 16:44:44 lol irony. proof* Jun 05 16:44:51 uhh well SIGINT only happens when you hit control-C in a terminal... which is why it only happened when you hit control-C in a terminal Jun 05 16:45:12 yeah actually i'm already watching for all signals that quit Jun 05 16:45:19 calling same handler for whichever Jun 05 16:45:33 SIGTERM is the signal that will be sent when shutdown is requested Jun 05 16:45:57 after which your process should have plenty of time... I think the default timeout is something silly like 2 minutes Jun 05 16:46:19 (for services) Jun 05 16:46:54 hm i'll check again. I think i used a library that wraps all the various signals. Jun 05 16:47:05 maybe it's got a flaow Jun 05 16:47:07 flaw Jun 05 16:48:26 (you can test it by simply stopping your service with systemctl of course, no need to perform a shutdown) Jun 05 16:56:25 I do see that my script is receiving SIGTERM but I guess it's not able to finish its destructor as compared to when I do SIGINT Jun 05 16:56:37 shouldn't make any difference Jun 05 16:56:52 once a signal is caught, it's caught Jun 05 16:57:00 stopping service triggers a SIGTERM? Jun 05 16:57:03 it has no futher impact on your program's execution Jun 05 16:57:04 yes Jun 05 16:57:53 and your service state will then become "stopping", and if you take really too long then systemd will shoot you down with a SIGKILL Jun 05 16:58:07 stopping the service works perfectly Jun 05 17:02:57 zmatt yeah looks like when I push that button and I see `avahi-daemon[967]: Got SIGTERM, quitting.`, my own script doesn't observe the SIGTERM as it does when I stop the service or SIGINT Jun 05 17:03:22 i have a handler that firsts prints to the log '*** got signal SIGTERM' which I don't see in this use case Jun 05 17:03:57 what does your service file look like? Jun 05 17:12:33 zmatt https://pastebin.com/W2iZ12er Jun 05 17:14:28 might have found a config in nodemon to do this better Jun 05 17:15:37 nevermind, already doing that Jun 05 17:15:51 lol what is the purpose of that startup script, besides confusing systemd about what's your main process? Jun 05 17:17:49 set WorkingDirectory to /home/debian/Documents/scanner/ and ExecStart to /path/to/npm start or /path/to/nodemon -r src/index.js Jun 05 17:19:34 btw, if you want better integration between systemd and your service, this module I wrote may be of interest: https://github.com/dutchanddutch/node-sd-daemon Jun 05 17:20:46 zmatt I do some config-pin calls in that startup first Jun 05 17:20:56 zmatt but I'm open to a better way, I think I just don't know any better Jun 05 17:21:06 you can use ExecStartPre in your service file for that Jun 05 17:21:36 or of course do the configuration in your node code instead ('config-pin' just writes values to sysfs files) Jun 05 17:22:13 at the very least if you do use a startup script, use 'exec' for the final command that starts your actual service Jun 05 17:25:17 are you saying that config-pin is unnecessary if I do it in node? I was wondering if that might be possible Jun 05 17:25:26 thanks for showing me that module, i'll check it out Jun 05 17:25:41 of course, config-pin is just a small shell script that writes values to files Jun 05 17:25:44 node can write values to files Jun 05 17:25:48 ok Jun 05 17:26:06 i've been using the onoff library, I think I'd do it with that Jun 05 17:26:40 I take all your advice, sounds like an improvement for running the service and I'll probably do this cleanup. Does any of it improve my original issue though about SIGTERM? Jun 05 17:26:48 you can find nodejs code for setting pin mode in bonescript of course Jun 05 17:27:05 I'm not using bonescript – but I could Jun 05 17:27:23 I'm not saying you should, but you can peek at what it's doing Jun 05 17:27:33 for the most part it's overly complicated Jun 05 17:28:06 most likely you can just configure your pins with one fs.writeFileSync per pin Jun 05 17:28:34 as for your SIGTERM issue, my guess would be it's due to systemd not knowing what your main pid is, as a result of your startup script Jun 05 17:28:39 brb pizza Jun 05 17:29:37 ah, that's a good theory. i'll see Jun 05 17:29:39 thx Jun 05 17:32:31 there are of course lots of workarounds for that, the quickest being to use 'exec' in your startup script Jun 05 17:39:01 ok cool Jun 05 18:18:03 zmatt so I changed ExecStart=/usr/bin/npm start and device is still working as expected but no luck with the button-press shutdown Jun 05 18:18:18 in terms of it triggering SIGTERM in node Jun 05 18:19:53 I don't actually see SIGTERM or SIG anything in the log Jun 05 18:20:08 only from before presumably when I did a systemctl stop on the service Jun 05 18:20:49 the only indication in the log is a series of Stopping/Stopped messages from systemd Jun 05 18:25:18 zmatt correction, same as before, I get "beaglebone avahi-daemon[987]: Got SIGTERM, quitting." before the "stopping" messages, but not the one I print out from node. Jun 05 18:25:50 think it's a question for the nodemon project? Jun 05 18:35:13 this is the script I am using that you gave me fwiw https://pastebin.com/U6xZXy63 Jun 05 18:45:55 uhh are you sure you linked to the right paste? Jun 05 18:47:35 and I'm not sure what problem you're still having. we have no problems with shutdown of nodejs services Jun 05 18:48:18 check whether the output of systemctl show -p MainPID your-service lists the correct pid (for the node process that is supposed to receive the SIGTERM) Jun 05 18:49:04 oh actually never mind, by default it sends SIGTERM to all processes in the control group Jun 05 18:50:07 that paste is the script you gave me to connect the button on the BB to halt Jun 05 18:50:28 ehm, no, that pastes prints out the mac address of the beaglebone Jun 05 18:50:40 *paste Jun 05 18:50:40 my problem is that SIGTERM isn't triggered when I used that button – some of the time it seems to be in syslog but never in node, so my node doesn't quit gracefully (my cleanup tasks don't get run) Jun 05 18:50:53 oh woops Jun 05 18:51:19 no, SIGTERM will be sent, but probably this is causing your service to exit immediately for some reason Jun 05 18:51:42 maybe we fixed that with a device tree fork. I think so Jun 05 18:51:56 zmatt yes I think you're right Jun 05 18:52:51 just to confirm, you're seeing the same problem when doing 'systemctl stop your-service' ? Jun 05 18:54:36 I can confirm that I do not se the problem when doing the above. In that case node does catch the signal and gracefully cleans up and quits Jun 05 18:55:36 huh Jun 05 18:55:43 this was the button fix: https://github.com/abcd-ca/dtb-rebuilder/commit/0ecbea0bfbb9d198529fa3a35190fc6319be1170 Jun 05 18:55:48 not sure if it's related Jun 05 18:56:00 wouldn't think so Jun 05 18:56:52 uhh, why are you adding those two lines in the &rtc block? Jun 05 18:57:16 and you're disabling the power button? Jun 05 18:57:18 I'm confused Jun 05 18:57:45 the original commit looks right, why do you have a revert for it? Jun 05 19:04:45 bbl Jun 05 19:05:58 ah wrong branch Jun 05 19:06:38 zmatt april 8 Jun 05 19:06:40 https://github.com/abcd-ca/dtb-rebuilder/commits/4.9-ti Jun 05 19:06:51 i reverted what I shouldn't have changed in the wrong branch before Jun 05 19:07:11 but if it looked right then it's the wrong rabbit hole to go down. Jun 05 19:11:44 bbl too Jun 05 19:14:22 sounds like git revert wasn't the comment you were looking for :) Jun 05 19:15:15 (this flowchart can be handy => http://justinhileman.info/article/git-pretty/ ) Jun 05 20:04:09 I see there is a "webinar" tomorrow on Element14. Jun 05 20:04:12 yea boy! Jun 05 20:04:21 More info! Jun 05 20:04:33 If the rains still come down over here, I am there. Jun 05 20:30:16 zmatt back, sorry did you have an idea why the SIGTERM doesn't do what we'd expect for the button-push vs the `systemctl stop` command? Jun 05 20:30:53 I think I appropriately reverted btw Jun 05 20:31:19 unlikely that no-one had seen the commit but since it's pushed, it's safer to revert in that case Jun 05 20:31:34 it's just a reverse commit Jun 05 21:04:31 I guess it depends on who the repository is for Jun 05 21:05:36 I guess the button-push isn't properly stopping your service or something? I don't know, hard to say Jun 05 21:10:04 for internal projects I don't feel any hesitation in undoing mistakes by rewriting history if noone is downstream, or if I'm not afraid of their wrath Jun 05 21:11:49 even moreso for projects that are basically just a patchset on top of some upstream project, which means I'd be rebasing all the time anyway Jun 05 22:00:18 zmatt sorry, meeting. Jun 05 22:00:49 hehe yeah, i know what you mean re git Jun 05 22:03:03 zmatt that's an interesting thought that the button might not be stopping my service. I had been imagining the opposite where it was shutting down too fast Jun 05 22:03:15 it's definitely fast – it halts in about 3-4s Jun 06 02:33:12 hmm, what is 47400000.dma-controller and why would it be going bananas? Jun 06 02:33:23 with interrupts? **** ENDING LOGGING AT Wed Jun 06 03:00:10 2018