Re: [HPLIP-Devel] Why are the HPLIP daemons required?

[Suffield, D. <dav...@hp...>]

Hi Johannes,

> perhaps it is a stupid question but I do not well understand=20
> why HPLIP requires continuously running processes (i.e. daemons).

Currently hpiod is a persistent daemon in order to maintain 1284.4/MLC
state for multiple clients/processes. 1284.4/MLC is a multi-point
transport over a single endpoint. Over this transport multiple channels
are supported for printing, scanning, status and faxing.

With that said, we have learned a lot since we have started the HPLIP
project and we have learned what is useful and what is not, so we are
looking into the possibility of a daemon-less version of HPLIP.

> The underlying problem of my question is that because of the=20
> daemons it is complicated to update HPLIP in a running system.
>=20
> The correct way to update HPLIP is:
> /etc/init.d/cups stop
> /etc/init.d/hplip stop
> replace the installed HPLIP files with the files of the new=20
> version /etc/init.d/hplip start /etc/init.d/cups start
>=20
> It is not possible to stop and start the services in an=20
> automated way (e.g. via RPM preinstall and postinstall=20
> scripts) because it is not possible to stop (and re-start)=20
> the whole printing service in an automated way when only one=20
> single printer driver package is to be updated because all=20
> currently printing jobs would be interrupted and re-printed=20
> from the very beginning which is not possible in particular=20
> in the business environment.

After an HPLIP update, you should be able to restart HPLIP with a single
command.=20

/etc/init.d/hplip restart

As long as there are no HPLIP print jobs active, a CUPS stop/restart is
not required.=20

-dave

> -----Original Message-----
> From: hpl...@li...=20
> [mailto:hpl...@li...] On Behalf=20
> Of Johannes Meixner
> Sent: Monday, February 26, 2007 5:41 AM
> To: hpl...@li...
> Subject: [HPLIP-Devel] Why are the HPLIP daemons required?
>=20
>=20
> Hello,
>=20
> perhaps it is a stupid question but I do not well understand=20
> why HPLIP requires continuously running processes (i.e. daemons).
>=20
> The underlying problem of my question is that because of the=20
> daemons it is complicated to update HPLIP in a running system.
>=20
> The correct way to update HPLIP is:
> /etc/init.d/cups stop
> /etc/init.d/hplip stop
> replace the installed HPLIP files with the files of the new=20
> version /etc/init.d/hplip start /etc/init.d/cups start
>=20
> It is not possible to stop and start the services in an=20
> automated way (e.g. via RPM preinstall and postinstall=20
> scripts) because it is not possible to stop (and re-start)=20
> the whole printing service in an automated way when only one=20
> single printer driver package is to be updated because all=20
> currently printing jobs would be interrupted and re-printed=20
> from the very beginning which is not possible in particular=20
> in the business environment.
>=20
> Therefore I think about what the inevitable reason is which=20
> requires continuously running processes but up to now I=20
> didn't find such a reason.
>=20
> My thoughts up to now:
>=20
> 1) Mutual exclusion:
> Mutual exclusion is needed when different users or processes=20
> try to access a device at the same time (e.g. one user prints=20
> while a second user wants to scan while a third user queries=20
> the device status).
> I think a usual lock file which contains device status info=20
> should be sufficient so that the other users can be informed=20
> if and why the device is currently in use.
>=20
> 2) Track the device status:
> Why continuously track the device status when no user or=20
> process asks for it?
> Shouldn't it be sufficient to query the device status from=20
> the lock file (if another process is currently accessing the=20
> device) or if no such file exists query it anew directly from=20
> the device?
>=20
> 3) Access permissions:
> Daemons which run as root seem to solve any access permission=20
> problem but actually they ignore any access permission policy.
> If there were no "root"-daemons, the established access=20
> permission policies of each Linux distribution could be used=20
> even for HPLIP.
>=20
>=20
> Kind Regards
> Johannes Meixner
> --
> SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg,=20
> Germany AG Nuernberg, HRB 16746, GF: Markus Rex
>=20
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT Join=20
> SourceForge.net's Techsay panel and you'll get the chance to=20
> share your opinions on IT & business topics through brief=20
> surveys-and earn cash=20
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
> &CID=3DDEVDEV
> _______________________________________________
> HPLIP-Devel mailing list
> HPL...@li...
> https://lists.sourceforge.net/lists/listinfo/hplip-devel
>=20