systemd: prctl: add PR_{SET, GET}_CHILD_SUBREAPER was Re: Did I buy the wrong network card? (RTL8812AE)

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

I'm top posting this information in the general interest, as I didn't truly get full persistence with the instructions I posted previously. I was ok for a soft reboot however, due to my particular situation, with neighborhood power outages coming up, I finally bought a UPS. When I rebooted the system this time Dbus couldn't connect the dots. I removed saned@.service & saned.socket from /lib/systemd/system/saned.service and rebooted. So considering all the other experiential outcomes I had read previously, jiggling color tanks etc. It looks like I'm facing an old nemisis ... colord - the neutral palate on which all else is drawn. There is missing Metadata No OwnerCmdline= for the scanner. Here's how that went. root@HECTOR:~# systemctl status colord.service ● colord.service - Manage, Install and Generate Color Profiles Loaded: loaded (/lib/systemd/system/colord.service; static) Active: active (running) since Wed 2017-05-17 07:22:17 EDT; 12h ago Main PID: 939 (colord) CGroup: /system.slice/colord.service └─939 /usr/lib/colord/colord May 17 18:42:14 HECTOR colord[939]: device removed: sysfs-Canon-MG2500_series May 17 18:42:14 HECTOR colord[939]: (process:5296): CdSane-WARNING **: fail...es May 17 18:42:19 HECTOR colord[939]: Device added: sysfs-Canon-MG2500_series May 17 18:42:48 HECTOR colord[939]: device removed: sysfs-Canon-MG2500_series May 17 18:42:50 HECTOR colord[939]: Device added: sysfs-Canon-MG2500_series May 17 18:43:07 HECTOR colord[939]: device removed: sysfs-Canon-MG2500_series May 17 18:43:09 HECTOR colord[939]: Device added: sysfs-Canon-MG2500_series May 17 18:43:43 HECTOR colord[939]: device removed: sysfs-Canon-MG2500_series May 17 18:43:43 HECTOR colord[939]: (process:5465): CdSane-WARNING **: fail...es May 17 18:50:08 HECTOR colord[939]: Device added: sysfs-Canon-MG2500_series Hint: Some lines were ellipsized, use -l to show in full. Tried the authors alias. ps xawf -eo pid,user,cgroup,args 926 root 4:devices:/system.slice/pol /usr/lib/policykit-1/polkitd --no-debug 939 colord 4:devices:/system.slice/col /usr/lib/colord/colord Ahaa, what's colord saying about the profiles. root@HECTOR:~# colormgr get-devices Object Path: /org/freedesktop/ColorManager/devices/cups_MG2500_series Owner: root Created: May 17 2017, 11:27:16 AM Modified: May 17 2017, 11:27:17 AM Type: printer Enabled: Yes Embedded: No Model: Canon MG2500 series Vendor: Canon Serial: B2090E&interface=1 Format: ColorModel.MediaType.Resolution Scope: temp Colorspace: rgb Device ID: cups-MG2500-series Profile 1: MG2500-series-RGB.. Profile 2: MG2500-series-Gray.. Metadata: OwnerCmdline=/usr/sbin/cupsd -f Object Path: /org/freedesktop/ColorManager/devices/sane_Canon_PIXMA_MG2500_Series Owner: colord Created: May 17 2017, 10:20:11 PM Modified: May 17 2017, 10:20:11 PM Type: scanner Enabled: Yes Embedded: No Model: Canon PIXMA MG2500 Series Vendor: CANON Serial: pixma:04A9176D_B2090E Scope: normal Colorspace: rgb Device ID: sane-Canon PIXMA MG2500 Series Metadata: OwnerCmdline= Possible bug? https://mail.gnome.org/archives/gnome-color-manager-list/2011-December/msg00... Well on Ubuntu there is this. avahi_simple_poll_prepare https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1351286 I've never heard Lennart Potterling speak, but right now I hear him in my head, in the voice of the Bandito from High Sierra, as he's saying ... POSIX we don't need no stinking POSIX. On Mon, May 15, 2017 at 9:44 AM, Russell <rreiter91@gmail.com> wrote:
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
-- Russell Sent by K-9 Mail

On Wed, May 17, 2017 at 9:44 PM, Russell <rreiter91@gmail.com> wrote: I'm top posting this information in the general interest, as I didn't truly get full persistence with the instructions I posted previously. Still not persistent but xsane works as colord profile now reports Metadata: OwnerCmdline=/usr/lib/colord/colord-sane I just have to wake the service when I want to scan. This didn't work previously until I fixed the ntp problem. <snip the middle> saned@0.service # Added by Russ for systemd requirements May 10, 2017 [Unit] Description=Scanner Service Requires=saned.socket [Service] ExecStart=/usr/sbin/saned User=saned Group=saned StandardInput=null StandardOutput=syslog StandardError=syslog Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255
Device ID: sane-Canon PIXMA MG2500 Series Metadata: OwnerCmdline=
Possible bug? https://mail.gnome.org/archives/gnome-color-manager-list/2011-December/msg00...
Well on Ubuntu there is this.
avahi_simple_poll_prepare
https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1351286
I've never heard Lennart Potterling speak, but right now I hear him in my head, in the voice of the Bandito from High Sierra, as he's saying ... POSIX we don't need no stinking POSIX.
<snip>
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
-- Russell Sent by K-9 Mail
-- Russell Sent by K-9 Mail
participants (1)
-
Russell