dbus-deamon avoiding reboot after upgrade

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

tomas@tuxteam.de
On Fri, Aug 16, 2019 at 11:06:43AM +0200, john doe wrote:

[...]

> Okay, as far as I understand it, depends means that it will be pulled as
> an dependency but not that it is required for it to work properly.
> What I'm starting to realise is that to much dependencies are pulled to
> implement lots of feature that is not always necessery.

That very much depends on the application: some (mis?) use dbus as a
dynamic linking facility which could be as well served by shared objects.

Kind of a Rube Goldberg way of doing dynamic linking -- but that's my
opinion, you'll find others.

Bluez is one example. Since it is the only bluetooth framework available
under Linux, that means: no dbus -> no bluetooth.

Others just complain that there's no dbus and carry on (X is one example.
This from my Xorg.0.log (line wrap by me):

  [   354.912] (EE) dbus-core: error connecting to system bus:
              org.freedesktop.DBus.Error.FileNotFound (Failed to connect
              to socket /var/run/dbus/system_bus_socket: No such file or
              directory)

> Before posting to the list, a google search let me think that dbus is
> only required when DE is wanted.
> Do you have online documentation that would explain why dbus is required
> when no DE is used?

It is a desktop invention (it was introduced by Havoc Pennington, after
much frustration trying to adopt Corba for the Gnome Desktop: compared
to that, DBus was, indeed, progress. KDE had a similar frustration with
its own distributed object monster -- uh -- model and followed suit).

But since then it has expanded to non-desktop things.

I've got quite a few beefs with DBus, which I won't expand here, but
that's why I try to find out how far I can go without it. Turns out,
for my use case, pretty far.

Cheers
-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

tomas@tuxteam.de
In reply to this post by Brian
On Fri, Aug 16, 2019 at 11:03:41AM +0100, Brian wrote:

[...]

> https://www.freedesktop.org/wiki/Software/dbus/
                  ^^^^^^^

;-)

[...]

> As Reco said:
>
>   > If you don't need it - just uninstall it.
>
> What do you get for 'apt purge dbus'?

Not the OP, but here's mine:

  tomas@trotzki:~$ sudo apt purge dbus
  [sudo] password for tomas:
  Reading package lists... Done
  Building dependency tree      
  Reading state information... Done
  Package 'dbus' is not installed, so not removed
  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

And this is:

  tomas@trotzki:~$ uname -a
  Linux trotzki 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64 GNU/Linux
  tomas@trotzki:~$ cat /etc/debian_version
  9.9

so it's Stretch, aka oldstable. And oh, of course with an X GUI.

Cheers
-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Brian
On Fri 16 Aug 2019 at 12:24:14 +0200, [hidden email] wrote:

> On Fri, Aug 16, 2019 at 11:03:41AM +0100, Brian wrote:
>
> [...]
>
> > https://www.freedesktop.org/wiki/Software/dbus/
>                   ^^^^^^^
>
> ;-)

DE - Desktop *Environment*. A case of selective censorship? :)

> [...]
>
> > As Reco said:
> >
> >   > If you don't need it - just uninstall it.
> >
> > What do you get for 'apt purge dbus'?
>
> Not the OP, but here's mine:
>
>   tomas@trotzki:~$ sudo apt purge dbus
>   [sudo] password for tomas:
>   Reading package lists... Done
>   Building dependency tree      
>   Reading state information... Done
>   Package 'dbus' is not installed, so not removed
>   0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

On my print server with buster:

    root@futro:~# apt purge dbus
    Reading package lists... Done
    Building dependency tree      
    Reading state information... Done
    The following packages will be REMOVED:
      dbus* libpam-systemd*
    0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded.
    After this operation, 1,057 kB disk space will be freed.

Mmm. I think Reco has led me to a state of enlightenment!

--
Brian.

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Brian
On Fri 16 Aug 2019 at 11:48:30 +0100, Brian wrote:

> On my print server with buster:
>
>     root@futro:~# apt purge dbus
>     Reading package lists... Done
>     Building dependency tree      
>     Reading state information... Done
>     The following packages will be REMOVED:
>       dbus* libpam-systemd*
>     0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded.
>     After this operation, 1,057 kB disk space will be freed.

Don't get the idea I am using lprng.  avahi-daemon is not on the list
because I choose not to advertise the print queues on this server.

--
Brian.

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

tomas@tuxteam.de
In reply to this post by Brian
On Fri, Aug 16, 2019 at 11:48:30AM +0100, Brian wrote:

> On Fri 16 Aug 2019 at 12:24:14 +0200, [hidden email] wrote:
>
> > On Fri, Aug 16, 2019 at 11:03:41AM +0100, Brian wrote:
> >
> > [...]
> >
> > > https://www.freedesktop.org/wiki/Software/dbus/
> >                   ^^^^^^^
> >
> > ;-)
>
> DE - Desktop *Environment*. A case of selective censorship? :)
Censorship? I didn't get that pun (promised! :)

[...]

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

tomas@tuxteam.de
In reply to this post by Brian
On Fri, Aug 16, 2019 at 11:54:50AM +0100, Brian wrote:

> On Fri 16 Aug 2019 at 11:48:30 +0100, Brian wrote:
>
> > On my print server with buster:
> >
> >     root@futro:~# apt purge dbus
> >     Reading package lists... Done
> >     Building dependency tree      
> >     Reading state information... Done
> >     The following packages will be REMOVED:
> >       dbus* libpam-systemd*
> >     0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded.
> >     After this operation, 1,057 kB disk space will be freed.
>
> Don't get the idea I am using lprng.  avahi-daemon is not on the list
> because I choose not to advertise the print queues on this server.
No, I didn't get that idea -- wasn't it you who reminded us that CUPS
doesn't require avahi-daemon?

Cheers
-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Brian
On Fri 16 Aug 2019 at 13:01:10 +0200, [hidden email] wrote:

> On Fri, Aug 16, 2019 at 11:54:50AM +0100, Brian wrote:
> > On Fri 16 Aug 2019 at 11:48:30 +0100, Brian wrote:
> >
> > > On my print server with buster:
> > >
> > >     root@futro:~# apt purge dbus
> > >     Reading package lists... Done
> > >     Building dependency tree      
> > >     Reading state information... Done
> > >     The following packages will be REMOVED:
> > >       dbus* libpam-systemd*
> > >     0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded.
> > >     After this operation, 1,057 kB disk space will be freed.
> >
> > Don't get the idea I am using lprng.  avahi-daemon is not on the list
> > because I choose not to advertise the print queues on this server.
>
> No, I didn't get that idea -- wasn't it you who reminded us that CUPS
> doesn't require avahi-daemon?

I don't think so; not in this thread anyway.

--
Brian.

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

tomas@tuxteam.de
On Fri, Aug 16, 2019 at 12:15:18PM +0100, Brian wrote:
> On Fri 16 Aug 2019 at 13:01:10 +0200, [hidden email] wrote:

[...]

> > No, I didn't get that idea -- wasn't it you who reminded us that CUPS
> > doesn't require avahi-daemon?
>
> I don't think so; not in this thread anyway.

I'm getting old, so this piqued somewhat my vanity. I double-checked:

In Message-ID: <[hidden email]>

[me]
>> CUPS depends on avahi depends somehow on dbus. Try some day lprng,
>> works a charm :-)

[you]
>> I forgot: the cups package does not depend on avahi-daemon; it is a
>> Recommends:. avahi-daemon does depend on dbus.

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Brian
On Fri 16 Aug 2019 at 13:21:11 +0200, [hidden email] wrote:

> On Fri, Aug 16, 2019 at 12:15:18PM +0100, Brian wrote:
> > On Fri 16 Aug 2019 at 13:01:10 +0200, [hidden email] wrote:
>
> [...]
>
> > > No, I didn't get that idea -- wasn't it you who reminded us that CUPS
> > > doesn't require avahi-daemon?
> >
> > I don't think so; not in this thread anyway.
>
> I'm getting old, so this piqued somewhat my vanity. I double-checked:
>
> In Message-ID: <[hidden email]>
>
> [me]
> >> CUPS depends on avahi depends somehow on dbus. Try some day lprng,
> >> works a charm :-)
>
> [you]
> >> I forgot: the cups package does not depend on avahi-daemon; it is a
> >> Recommends:. avahi-daemon does depend on dbus.

It's a fair cop!

--
Brian.

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

tomas@tuxteam.de
On Fri, Aug 16, 2019 at 12:46:17PM +0100, Brian wrote:
> On Fri 16 Aug 2019 at 13:21:11 +0200, [hidden email] wrote:

> > I'm getting old, so this piqued somewhat my vanity. I double-checked:

[...]

> It's a fair cop!

:-)

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Greg Wooledge
In reply to this post by Reco
On Fri, Aug 16, 2019 at 09:53:20AM +0300, Reco wrote:

> On Thu, Aug 15, 2019 at 10:36:57PM +0100, Brian wrote:
> > On Thu 15 Aug 2019 at 22:15:59 +0100, Tixy wrote:
> >
> > > On Thu, 2019-08-15 at 19:41 +0100, Brian wrote:
> > > > The fact remains that dbus is not a DE only package. How did anyone
> > > > get the idea it was?
> > >
> > > Perhaps because D-Bus stands for Desktop Bus and according to Wikipedia
> > > [1]
> > >
> > >    D-Bus was developed as part of the freedesktop.org project [...] to
> > >    standardize services provided by Linux desktop environments such as
> > >    GNOME and KDE.
> > >
> > > It's seems quite reasonable to me for people to jump to the conclusion
> > > that it's not likely relevant for servers.
> > >
> > > [1] https://en.wikipedia.org/wiki/D-Bus
> >
> > Jumping to conclusions is the ideal way of neglecting facts and promoting
> > fallacious assertions. I have given two examples that challenge
> >
> >   dbus "...is redundant for typical server software"
>
> The first one being "apt cache rdepends"? You can do better than this.
>
> The second one being CUPS? dbus is not required for printing itself.

Also, most servers don't deal with ink-and-paper printing.  At all.

Brian asked how people would conclude things about D-Bus, and Tixy gave
a completely legitimate answer.  It was an answer I had been considering
writing myself, but I was lazy.

The name is *literally* an abbreviation for Desktop Bus, and you (Brian)
claim you don't understand why people think it's only for desktop systems?
Come on.

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Brian
On Fri 16 Aug 2019 at 08:39:43 -0400, Greg Wooledge wrote:

> On Fri, Aug 16, 2019 at 09:53:20AM +0300, Reco wrote:
> > On Thu, Aug 15, 2019 at 10:36:57PM +0100, Brian wrote:
> > > On Thu 15 Aug 2019 at 22:15:59 +0100, Tixy wrote:
> > >
> > > > On Thu, 2019-08-15 at 19:41 +0100, Brian wrote:
> > > > > The fact remains that dbus is not a DE only package. How did anyone
> > > > > get the idea it was?
> > > >
> > > > Perhaps because D-Bus stands for Desktop Bus and according to Wikipedia
> > > > [1]
> > > >
> > > >    D-Bus was developed as part of the freedesktop.org project [...] to
> > > >    standardize services provided by Linux desktop environments such as
> > > >    GNOME and KDE.
> > > >
> > > > It's seems quite reasonable to me for people to jump to the conclusion
> > > > that it's not likely relevant for servers.
> > > >
> > > > [1] https://en.wikipedia.org/wiki/D-Bus
> > >
> > > Jumping to conclusions is the ideal way of neglecting facts and promoting
> > > fallacious assertions. I have given two examples that challenge
> > >
> > >   dbus "...is redundant for typical server software"
> >
> > The first one being "apt cache rdepends"? You can do better than this.
> >
> > The second one being CUPS? dbus is not required for printing itself.
>
> Also, most servers don't deal with ink-and-paper printing.  At all.

I don't quite follow that, but is it of great importance? Some do, and
then dbus will be involved in advertising print queues to clients.

> Brian asked how people would conclude things about D-Bus, and Tixy gave
> a completely legitimate answer.  It was an answer I had been considering
> writing myself, but I was lazy.
>
> The name is *literally* an abbreviation for Desktop Bus, and you (Brian)
> claim you don't understand why people think it's only for desktop systems?
> Come on.

I own up to reading solely the primary source at freedesktop. I can find
no reference there to dbus being required only when (to quote John Doe)

 > a DE (Gnome,Mate, ...) is present.

Whatever the genesis of the application's name and function, it has
evidently moved on in the last 10+ years. firewalld (which looks like a
good candidate for use on a server) also depends on dbus.

--
Brian.


Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Brian
In reply to this post by Reco
On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote:

> On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
>
> > Nowadays that system often relies on printer/print queue Bonjour
> > broadcasts.
>
> And that is called "jumping to conclusions".
> Printing itself haven't changed a bit for last 15 years - a print server
> takes user's PS or PDF, mangles it to fit printer's representation (be
> it PCL or something else), and feeds it to the printer. By utilizing
> unicasts of course.

I was going to let this go because it takes us beyond the server
situation we are discussing and is a reasonable, succinct description
of classic printing (which will become unsupported by CUPS in a few
years time).

However, modern printers will accept and print jobs (e.g. PDF and JPEG)
without the mangling. These AirPrint-enabled, IPP printers completely
do away with having to use non-free software or plugins also. What is
there to dislike about that?

> A user can discover a print server via mDNS multicasts (*not*
> broadcasts). Or a user can be told a location of such print server.

So - I give my VIP, Android-using customer a piece of paper with a URI
to type into his phone rather than telling him which printer to use to
print out the multimillion Euro contract he has just signed? Very last
century. Anyone fancy carrier pigeons?

--
Brian.

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Reco
On Fri, Aug 16, 2019 at 07:14:58PM +0100, Brian wrote:

> On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote:
>
> > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
> >
> > > Nowadays that system often relies on printer/print queue Bonjour
> > > broadcasts.
> >
> > And that is called "jumping to conclusions".
> > Printing itself haven't changed a bit for last 15 years - a print server
> > takes user's PS or PDF, mangles it to fit printer's representation (be
> > it PCL or something else), and feeds it to the printer. By utilizing
> > unicasts of course.
>
> I was going to let this go because it takes us beyond the server
> situation we are discussing and is a reasonable, succinct description
> of classic printing (which will become unsupported by CUPS in a few
> years time).
>
> However, modern printers will accept and print jobs (e.g. PDF and JPEG)
> without the mangling. These AirPrint-enabled, IPP printers completely
> do away with having to use non-free software or plugins also. What is
> there to dislike about that?

Nothing. But it also means that one only needs something like ipptool
([1]) on client-side, leaving CUPS (and a whole notion of a "print
server") out of the equation completely.


> > A user can discover a print server via mDNS multicasts (*not*
> > broadcasts). Or a user can be told a location of such print server.
>
> So - I give my VIP, Android-using customer a piece of paper with a URI
> to type into his phone rather than telling him which printer to use to
> print out the multimillion Euro contract he has just signed?
> Very last century.

Multicasts are limited to a single L2 network segment by their very
definition.
Putting your printers (or print servers) within a guest network (WiFi
for Android customers) - that's a last century indeed.

Besides, "multimillion Euro contract" can involve some pretty secretary
lady who's happy to print said contract. Just saying.

Reco

[1] https://github.com/istopwg/ippsample

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Brian
On Fri 16 Aug 2019 at 22:39:09 +0300, Reco wrote:

> On Fri, Aug 16, 2019 at 07:14:58PM +0100, Brian wrote:
> > On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote:
> >
> > > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
> > >
> > > > Nowadays that system often relies on printer/print queue Bonjour
> > > > broadcasts.
> > >
> > > And that is called "jumping to conclusions".
> > > Printing itself haven't changed a bit for last 15 years - a print server
> > > takes user's PS or PDF, mangles it to fit printer's representation (be
> > > it PCL or something else), and feeds it to the printer. By utilizing
> > > unicasts of course.
> >
> > I was going to let this go because it takes us beyond the server
> > situation we are discussing and is a reasonable, succinct description
> > of classic printing (which will become unsupported by CUPS in a few
> > years time).
> >
> > However, modern printers will accept and print jobs (e.g. PDF and JPEG)
> > without the mangling. These AirPrint-enabled, IPP printers completely
> > do away with having to use non-free software or plugins also. What is
> > there to dislike about that?
>
> Nothing. But it also means that one only needs something like ipptool
> ([1]) on client-side, leaving CUPS (and a whole notion of a "print
> server") out of the equation completely.

ipptool depends on libcups2.

> > > A user can discover a print server via mDNS multicasts (*not*
> > > broadcasts). Or a user can be told a location of such print server.
> >
> > So - I give my VIP, Android-using customer a piece of paper with a URI
> > to type into his phone rather than telling him which printer to use to
> > print out the multimillion Euro contract he has just signed?
> > Very last century.
>
> Multicasts are limited to a single L2 network segment by their very
> definition.

DNS-SD/Bonjour not scaling on typical multi-segment networks is a
recognised issue by CUPS upstream. Developments at

 https://tools.ietf.org/wg/dnssd/

could produce a solution that CUPS could take advantage of.
 
> Putting your printers (or print servers) within a guest network (WiFi
> for Android customers) - that's a last century indeed.
>
> Besides, "multimillion Euro contract" can involve some pretty secretary
> lady who's happy to print said contract. Just saying.

I have no idea whether a secretary likes to be typecast, but is being
pretty, male and amenable a prerequisite to obtaining the post?

Anyway, the secretary has knocked off and I am left to instruct my VIP
how to use his Android phone to type the printer location without a
mistype:

 dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2

So much for telling a user a location. While he is typing I could rivet
him with describing the difference between a broadcast and a multicast.

--
Brian.

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Reco
On Fri, Aug 16, 2019 at 11:23:48PM +0100, Brian wrote:

> On Fri 16 Aug 2019 at 22:39:09 +0300, Reco wrote:
>
> > On Fri, Aug 16, 2019 at 07:14:58PM +0100, Brian wrote:
> > > On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote:
> > >
> > > > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
> > > >
> > > > > Nowadays that system often relies on printer/print queue Bonjour
> > > > > broadcasts.
> > > >
> > > > And that is called "jumping to conclusions".
> > > > Printing itself haven't changed a bit for last 15 years - a print server
> > > > takes user's PS or PDF, mangles it to fit printer's representation (be
> > > > it PCL or something else), and feeds it to the printer. By utilizing
> > > > unicasts of course.
> > >
> > > I was going to let this go because it takes us beyond the server
> > > situation we are discussing and is a reasonable, succinct description
> > > of classic printing (which will become unsupported by CUPS in a few
> > > years time).
> > >
> > > However, modern printers will accept and print jobs (e.g. PDF and JPEG)
> > > without the mangling. These AirPrint-enabled, IPP printers completely
> > > do away with having to use non-free software or plugins also. What is
> > > there to dislike about that?
> >
> > Nothing. But it also means that one only needs something like ipptool
> > ([1]) on client-side, leaving CUPS (and a whole notion of a "print
> > server") out of the equation completely.
>
> ipptool depends on libcups2.

Which does not make it require CUPS on the other side - [2].
And note - a conventional RFC1918 IP is used there. No "discovery"
involved.


> > > > A user can discover a print server via mDNS multicasts (*not*
> > > > broadcasts). Or a user can be told a location of such print server.
> > >
> > > So - I give my VIP, Android-using customer a piece of paper with a URI
> > > to type into his phone rather than telling him which printer to use to
> > > print out the multimillion Euro contract he has just signed?
> > > Very last century.
> >
> > Multicasts are limited to a single L2 network segment by their very
> > definition.
>
> DNS-SD/Bonjour not scaling on typical multi-segment networks is a
> recognised issue by CUPS upstream.

An interesting example of corporate doublespeak, but it does not change
what I wrote - you need multicasts working - you put both sender and
receiver in a single network segment.
And that's bad for security, and is so last century.


> > Besides, "multimillion Euro contract" can involve some pretty secretary
> > lady who's happy to print said contract. Just saying.
>
> I have no idea whether a secretary likes to be typecast, but is being
> pretty, male and amenable a prerequisite to obtaining the post?
>
> Anyway, the secretary has knocked off and I am left to instruct my VIP
> how to use his Android phone to type the printer location without a
> mistype:
>
>  dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2

You overcomplicate things without the need.
ipp://<ur_printer> is all you need.

Reco

[2] https://stackoverflow.com/questions/19232082/printing-using-ipp-without-drivers-ipp-client

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Brian
On Sat 17 Aug 2019 at 12:59:16 +0300, Reco wrote:

> On Fri, Aug 16, 2019 at 11:23:48PM +0100, Brian wrote:
> >
> > ipptool depends on libcups2.
>
> Which does not make it require CUPS on the other side - [2].
> And note - a conventional RFC1918 IP is used there. No "discovery"
> involved.

Anything from Kurt Pfeifle is always a worthwhile read.
 
> > DNS-SD/Bonjour not scaling on typical multi-segment networks is a
> > recognised issue by CUPS upstream.
>
> An interesting example of corporate doublespeak, but it does not change
> what I wrote - you need multicasts working - you put both sender and
> receiver in a single network segment.
> And that's bad for security, and is so last century.

I don't think the principal upstream CUPS developer is given to
speaking with a forked tongue or pulling the wool over people's
eyes,

> > Anyway, the secretary has knocked off and I am left to instruct my VIP
> > how to use his Android phone to type the printer location without a
> > mistype:
> >
> >  dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2
>
> You overcomplicate things without the need.

Neither myself nor my VIP know what we are doing. We just wish the
sysadmin had had the commensense to set up printing so a tap on a
queue/printer name would have sufficed.

> ipp://<ur_printer> is all you need.

Eventually we hit on ipp://<IP_address>/<resource>. The resource name
format depends on whether a queue or printer is being printed to.

--
Brian.

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Brian
In reply to this post by john doe-6
On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote:

> Hi,
>
> While upgrading the dbus deamon, I get the following:
>
> "A reboot is required to replace the running dbus-daemon.
> Please reboot the system when convenient."
>
>
> I have no plan to reboot that server, what are the pros and cons of not
> doing that or how can I avoid rebooting altogether?

In the light of Curt's reference to #805449 and your reluctance to
provide any extra information on the server setup you have in mind,
your plan will have to accomodate reality. Reboot and be done with
it.

--
Brian.

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

john doe-6
On 8/17/2019 8:15 PM, Brian wrote:

> On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote:
>
>> Hi,
>>
>> While upgrading the dbus deamon, I get the following:
>>
>> "A reboot is required to replace the running dbus-daemon.
>> Please reboot the system when convenient."
>>
>>
>> I have no plan to reboot that server, what are the pros and cons of not
>> doing that or how can I avoid rebooting altogether?
>
> In the light of Curt's reference to #805449 and your reluctance to
> provide any extra information on the server setup you have in mind,
> your plan will have to accomodate reality. Reboot and be done with
> it.
>

From reading this thread, here's what I understand:

Despide the word desktop being thrown everyware (URL of the page given
in this thread, ...) it has now moved to be use or at the very least
installed, on non-desktop host.

If the above is correct, is there a rule to determine if dbus is required?
Relying on apt/apt-get is something that I'm not comfortable with! :)


Thanks to anyone who has given me their thoughts.


--
John Doe

Reply | Threaded
Open this post in threaded view
|

Re: dbus-deamon avoiding reboot after upgrade

Brian
On Sun 18 Aug 2019 at 12:17:59 +0200, john doe wrote:

> On 8/17/2019 8:15 PM, Brian wrote:
> > On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote:
> >
> >> Hi,
> >>
> >> While upgrading the dbus deamon, I get the following:
> >>
> >> "A reboot is required to replace the running dbus-daemon.
> >> Please reboot the system when convenient."
> >>
> >>
> >> I have no plan to reboot that server, what are the pros and cons of not
> >> doing that or how can I avoid rebooting altogether?
> >
> > In the light of Curt's reference to #805449 and your reluctance to
> > provide any extra information on the server setup you have in mind,
> > your plan will have to accomodate reality. Reboot and be done with
> > it.
> >
>
> From reading this thread, here's what I understand:
>
> Despide the word desktop being thrown everyware (URL of the page given
> in this thread, ...) it has now moved to be use or at the very least
> installed, on non-desktop host.
>
> If the above is correct, is there a rule to determine if dbus is required?
> Relying on apt/apt-get is something that I'm not comfortable with! :)

The -s option to apt could make you feel more comfortable if you are
concerned about damaging the system. Otherwise, 'aptitude why dbus'.

--
Brian.

123