I've changed the subject to indicate that I have changed my own system by following the instructions to initialize ifup-wait-all-auto.service and this sub initialization feature seems to have fixed my npdate issue. On my box, I still have a minor memory allocation problem. Although the USB error showing the HID description (usually only one physical Endpoint on a human interface device) is gone. The system.slice also links this error to wpa_supplicant. However, today cron.daily executed ntpdate correctly. root@HECTOR:~# systemctl status ntp.service ● ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp) Active: active (running) since Sun 2017-05-14 09:31:35 EDT; 22h ago CGroup: /system.slice/ntp.service └─22736 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 120:127 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... I've added this to my .bashrc as the authors of systemd recommend for further core troubleshooting. alias psc='ps xawf -eo pid,user,cgroup,args' On Sun, May 14, 2017 at 4:14 PM, Russell Reiter <rreiter91@gmail.com> wrote:
On Sat, May 13, 2017 at 1:55 PM, Stewart C. Russell via talk <talk@gtalug.org> wrote:
On 2017-05-13 12:24 PM, Russell wrote:
This might be an ILP (Instruction Level Parallelisim) feature of systemd init.
Take a look at how systemd deals with IVP routing tables using network.target here.
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Thanks, but I'm getting network, then it's periodically cutting out. This seems to be more waiting for systemd to say "No, really, we've got a network available" to services, rather than the network giving out. We get to answer a lot of questions about systemd and network on the Raspberry Pi forum, mostly about @reboot cron jobs not finding the network.
For now, perhaps you could help me out? Are you getting this following usbhid endpoint error?
usbhid 1-2:1.0: couldn't find an input interrupt endpoint
Also sorry I wasn't clear in my earlier post. The page link I provided was to the page NetworkTarget. network.target itself only indicates that the network management stack is up after it has been reached, It was the stuff below the "Cut the crap! How do I make network.target work for me", that I was referring to.
The reason I ask is that, here on my stock Debian, I seem to have some confusion as an endpoint buffer, which firstly needs an endpoint descriptor, doesn't get one. If a service doesn't return NAK or STALL, the result seems to be a missing link beat.
Once a core system acquires the target, you should be able to track that target by its Endpoint device description tables, in theory anyway.
However, when something tries to shove a big endian bit into a little endian bucket, stuff is bound to spill over and mux something up.
So far, I was able to sort out my own printer/scanner and a non-persistent scanner, by defining /lib/systemd/system - saned@.service -saned.socket
Right now for a NTP issue I'm studying - After=network-online.target -Wants=network-online.target
I dont have network dropping issue but some people who are dropping networks after the initial poll might have luck with.
systemctl enable ifup-wait-all-auto.service
Below is a quote from another link which also contains the suggested contents of ifup-wait-all-auto.service.
https://unix.stackexchange.com/questions/209832/debian-systemd-network-onlin...
"Throw that beauty in /etc/systemd/system/ifup-wait-all-auto.service, install it with sudo systemctl enable ifup-wait-all-auto.service, and then actually have the network-online.target references in your systemd unit definitions work properly."
Thanks, though. I suspect I'll have to make do with a very basic USB wifi adapter (I bought Far Too Many for Raspberry Pis) until Scott's suggested mPCIe adapter arrives.
cheers, Stewart
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
-- Russell Sent by K-9 Mail