hp-confg_usb_printer hangs in loop.

Created attachment 363938
emerge --info

With net-print/hplip-3.13.9 my system experiences a delay during boot. It sits at the "Waiting for uevents to be processed" message for about 30 seconds. The system boots without delay with net-print/hplip-3.12.10a.

udev debug shows the following at approx. 30 seconds into boot.

[ 34.129450] udevd[311]: timeout '/bin/sh -c 'if [ -f /usr/bin/systemctl ]; then /usr/bin/systemctl --no-block start hplip-printer@002:003.service; else /usr/bin/nohup /usr/bin/hp-config_usb_printer 002:003 ; fi''
[ 34.187935] udevd[293]: worker [311] /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5 timeout; kill it

The first line comes from /lib/udev/rules.d/56-hpmud.rules which was introduced with hplip-3.13.5.

After some googling I applied the fix from Slackware 14.1 which simply backgrounds the nohup call in /lib/udev/rules.d/56-hpmud.rules. Now the system boots without delay.

There is also a bug on Launchpad[1] regarding this issue but with a slightly different fix.

However with both fixes I see the following from udev debug.

[ 3.457962] udevd[310]: '/bin/sh -c 'if [ -f /usr/bin/systemctl ]; then /usr/bin/systemctl --no-block start hplip-printer@002:003.service; else /usr/bin/nohup /usr/bin/hp-config_usb_printer 002:003 & ; fi''(err) '/bin/sh: -c: line 0: syntax error near unexpected token `;

I'm not sure if this is a problem but printing works so far.

[1] https://bugs.launchpad.net/hplip/+bug/1185866

Created attachment 363940
dmesg debug log

Created attachment 363942
slackware 56-hpmud.rules background patch

Well it seems that the syntax error I mentioned in comment #1 prevents /usr/bin/hp-config_usb_printer from being executed. If I remove the trailing ';' the syntax error goes away but then the "fix" from Slackware doesn't work as the boot is delayed again.

The fix from launchpad does work but without the trailing ';' but then I get the following from udev debug.

/bin/sh: /var/log/hp/hplip_config_usb_printer.err: Read-only file system'

I'm not sure if this prevents /usr/bin/hp-config_usb_printer from executing but the system boot isn't delayed.

Created attachment 363994
hplip nohup blocking patch

I have taken the fix from launchpad, removed the trailing ';' and redirected standard out/err to /run instead of /var/log. I'm not sure if using /run is correct.

Now the system boots without delay and /usr/bin/hp-config_usb_printer appears to run without any errors from udev.

From reading the upstream bug this has been fixed since 3.13.6. The fix was adding /usr/bin/nohup in front of the /usr/bin/hp-config_usb_printer call.

The slackware patch and your patch are based on the fixed version 3.13.6 so apparently the fix was not correct as using nohup alone does not seem to work.

Backgrounding is required with or without using nohup. As you found out when backgrounding a command the semicolon is not needed anymore as it works as separator already.

There are other solutions as well:

Background the command using an ampersand and remove the semicolon like you did:
if [ something ]; then echo 1& else echo 2 ; fi

Use the semicolon as usual and background the complete if-then-else clause
if [ something ]; then echo 1; else echo 2 ; fi &

Or in a script by using line breaks:
if [ something ]
then
 echo 1 &
else
 echo 2
fi

Backgrounding the in/output is another issue. Apparently with nohup it should be used to prevent hanging in case the program sends or receives in/output. Best would be to redirect the complete in/output:
if [ something ]; then echo 1 >/dev/null 2>&1 </dev/null & else echo 2 ; fi

Thank you for looking into this issue. I tried some of your suggestions with the following results.

- Without nohup, background 'if-then-else', without redirects
Boot is delayed.

- Without nohup, background only 'else', without redirects
Boot is delayed.

- With nohup, background only the 'else', redirect i/o to null
Boot isn't delayed. udev debug shows 'exit with return code 0'. I'm assuming this means it was successful?

I now use the following:

if [ something ]; then blob; else /usr/bin/nohup /usr/bin/hp-config_usb_printer $env{BUSNUM}:$env{DEVNUM} >/dev/null 2>&1 </dev/null & fi

I think this is much better than redirecting output /run.

(In reply to BT from comment #6)
> Thank you for looking into this issue. I tried some of your suggestions with
> the following results.
>
> - Without nohup, background 'if-then-else', without redirects
> Boot is delayed.
>
> - Without nohup, background only 'else', without redirects
> Boot is delayed.
>
> - With nohup, background only the 'else', redirect i/o to null
> Boot isn't delayed. udev debug shows 'exit with return code 0'. I'm assuming
> this means it was successful?
>
> I now use the following:
>
> if [ something ]; then blob; else /usr/bin/nohup
> /usr/bin/hp-config_usb_printer $env{BUSNUM}:$env{DEVNUM} >/dev/null 2>&1
> </dev/null & fi
>
> I think this is much better than redirecting output /run.

So nohup is required, I just did some quick tests on the command line. Also using /dev/null as redirection target was just an example. Using /var/log/hp should be better.

Do you have /var on a different partition? Maybe this is causing the write errors as the filesystem is not mounted when trying to write there.

(In reply to Daniel Pielmeier from comment #7)
> Do you have /var on a different partition? Maybe this is causing the write
> errors as the filesystem is not mounted when trying to write there.

No it's not on a separate partition. From what I can gather, root is mounted read-only at that point in boot process.

(In reply to BT from comment #8)
> (In reply to Daniel Pielmeier from comment #7)
> > Do you have /var on a different partition? Maybe this is causing the write
> > errors as the filesystem is not mounted when trying to write there.
>
> No it's not on a separate partition. From what I can gather, root is mounted
> read-only at that point in boot process.

Well then /dev/null or /run makes sense.

+*hplip-3.13.11-r1 (30 Nov 2013)
+
+ 30 Nov 2013; Daniel Pielmeier <email address hidden> +hplip-3.13.11-r1.ebuild:
+ Revision bump to fix bug #492486. Thanks to BT for the report and the patch.

I have just added the patch which uses /dev/null for redirection.