LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Current: udev problem with hplip-3.13.5/1 (http://www.linuxquestions.org/questions/slackware-14/current-udev-problem-with-hplip-3-13-5-1-a-4175463005/)

burdi01 05-22-2013 09:27 AM

Current: udev problem with hplip-3.13.5/1
 
Current: Since the May 20 upgrade of hplip from 3.13.3/2 to 3.13.5/1 I experience a longish hiccup at system boot, after which the following text is displayed on the console:
Quote:

udevd[218]: timeout: killing '/bin/sh -c 'if [ -f /usr/bin/systemctl ]; then /usr/bin/systemctl --no-blank start hplip-printer@004:005.service; else /usr/bin/hp-config-usb-printer 004:005; fi'' [421]
udevd[218]: '/bin/sh -c 'if [ -f /usr/bin/systemctl ]; then /usr/bin/systemctl --no-blank start hplip-printer@004:005.service; else /usr/bin/hp-config-usb-printer 004:005; fi'' [421] terminated by signal 9 (Killed)
This command comes from /lib/udev/rules.d/56-hpmud.rules; commenting out the pertinent line therein eliminates the hiccup, while printing and scanning are not affected.
:)

volkerdi 05-22-2013 09:35 AM

systemctl... sigh.

burdi01 05-22-2013 11:22 AM

I have no /usr/bin/systemctl, but for sure I have a /usr/bin/hp-config_usb_printer -> ../share/hplip/config_usb_printer.py*
:)

zakame 05-22-2013 11:59 AM

Yech. Seems like the (n)ew package also snuck in a systemd service file as well:

Code:

zakame@jazz:~% grep systemd /var/log/packages/hplip-3.13.5-x86_64-1
usr/lib/systemd/
usr/lib/systemd/system/
usr/lib/systemd/system/hplip-printer@.service


ReaperX7 05-22-2013 08:43 PM

Check the source's makefile with "make --configure" to see if the package for systemd can be disabled on build with a switch, like --disable-systemd.

volkerdi 05-22-2013 10:28 PM

I think the problem really isn't directly to do with systemd, although changes made to support systemd may have brought it about. When exactly does this "hiccup" occur? Is it possibly during the initrd execution? If that's the case the fix will be blacklisting that rule from being copied to an initrd.

A good test to see if this is the case would be to leave the rule on the main system, but delete it from under /boot/initrd-tree, and then use mkinitrd (with no options) to rebuild the initrd without the rule. Reinstall lilo, reboot, and if it doesn't happen we know what the deal was.

zakame 05-23-2013 02:18 AM

I'm wondering where /etc/udev/rules.d/56-hpmud.rules came from. My hplip on 14.0 installed /etc/udev/rules.d/86-hpmud-hp_laserjet_*.rules files (as I'm using an old P1505n here at $WORK,) so I suspect the proprietary stuff that one downloads upon installing the printerr may be the culprit.

burdi01 05-23-2013 07:15 AM

The hiccup occurs on the main system, not in the initrd.

Actually this specific rule would make no sense in an initrd - not only is there no /usr/bin/systemctl but there is no /usr/bin/hp-config_usb_printer as well.

Things bring me to the more fundamental observation that udev does not seem to run at all in the initrd. I have an "all modules" kernel and if I do not specify the block and filesystem drivers via "mkinitrd -c -m ahci:ata_piix:ext3 -k 3.9.2-burdi64" booting will fail.
:)

guanx 05-23-2013 08:07 AM

Quote:

Originally Posted by burdi01 (Post 4957173)
...

Things bring me to the more fundamental observation that udev does not seem to run at all in the initrd. I have an "all modules" kernel and if I do not specify the block and filesystem drivers via "mkinitrd -c -m ahci:ata_piix:ext3 -k 3.9.2-burdi64" booting will fail.
:)

Of course the modules cannot be loaded when they are not there. The "/lib/modules/" directory on the main system is not available before the main system is mounted.

Udev is run indeed. You can open "/boot/initrd-tree/init" with a text editor and see.

burdi01 05-23-2013 10:57 AM

As a longtime Slacker using an initrd I opened "/boot/initrd-tree/init" with a text editor to see many, many times. Of course udevd is run, but in my opinion it does not do anything:
-- setting /etc/udev/udev.conf > udev_log="debug" shows output
-- in /init commenting out the /load_kernel_modules invocation makes booting fail
-- in /init commenting out the udevd invocation instead makes booting successful.

In other words: (At least in my use case) including udev in the initrd is superfluous.
:)

burdi01 05-28-2013 04:46 AM

To recap: This thread has two subthreads:
a. The hiccup at boot;
b. Udev in the initrd.

Ad a:
I am still running with the pertinent line in /lib/udev/rules.d/56-hpmud.rules commented out. I have not seen any effects on printing and/or scanning.

Ad b:
To me it seems that udev in the initrd does run, but does not do anything. At least in my use case this has no consequences.

:)

timkb4cq 05-31-2013 10:18 AM

I just got finished troubleshooting this for a package for MEPIS 12 (now in beta).
If your system was using systemd instead of some version of sysvinit, the hplip udev rule wouldn't block udev on startup causing the delay. The second branch launching hp-config_usb_printer does block. It sits in a 12x loop with a wait(5) in each trying to delete extraneous printer queues, so it blocks udev for 1:05

If your printer doesn't use a plugin, commenting out the line works fine. If your HP does use a plugin you may need hp-config_usb_printer to run.

I solved the issue by detaching hp-config_usb_printer from udev by starting it with nohup like so:
Code:

# This rule will add the printer and install plugin
ENV{hp_test}=="yes", PROGRAM="/bin/sh -c 'logger -p user.info loading HP Device $env{BUSNUM} $env{DEVNUM}'", RUN+="/bin/sh -c 'if [ -f /usr/bin/systemctl ]; then /usr/bin/systemctl --no-block start hplip-printer@$env{BUSNUM}:$env{DEVNUM}.service; else /usr/bin/nohup /usr/bin/hp-config_usb_printer $env{BUSNUM}:$env{DEVNUM} 2>/var/log/hp/hplip_config_usb_printer.err &; fi'"

Redirecting the error messages with the 2> was necessary to keep it from blocking even though none are produced...

There's also a typo in line 260 of hplip3.13.5/config_usb_printer.py where they spelled utils as utlis. This will keep some printers from loading their plugins. If you rebuild might as well fix this too
And there are added debugging messages left in HPCupsFilter.cpp that flood the syslog with
Code:

prnt/hpcups/HPCupsFilter.cpp 157: ERROR: File pointer is NULL!
messages when you print...

burdi01 06-01-2013 05:00 AM

So my LaserJet 3020 does not need a plugin. :)
Nevertheless I applied your two fixes. And indeed the hiccup does not occur.
Thank you very much.
:D

burdi01 06-05-2013 03:50 AM

Timkb4cq's patch is included in ap/hplip-3.13.5-i486-2.txz as published on Tue Jun 4 23:30:57 UTC 2013.
:D

cwizardone 08-26-2013 04:41 PM

@burdi01,

Many thanks. I had the same hiccup with hplip-3.13.8.

:hattip:


All times are GMT -5. The time now is 02:13 PM.