Shouldn't pacman restart dovecot after update?

[David C. Rankin]

Guys,

Sending mail from my local server resulted in errors "could not copy sent mail
to 'sent' on servername? Checking the mail logs, I found this:

<snip>
Aug 2 17:15:03 nirvana dovecot: imap-login: Fatal: Dovecot version mismatch:
Master is v1.2.12, login is v1.2.13 (if you don't care, set version_ignore=yes)
Aug 2 17:15:03 nirvana dovecot: imap-login: Fatal: Dovecot version mismatch:
Master is v1.2.12, login is v1.2.13 (if you don't care, set version_ignore=yes)
<snip>

So I restarted dovecot -- problem solved. That brought up the question, why
didn't pacman restart dovecot with some post-install something?? So should it
have? If it didn't, does this need to be reported?

Let me know. Thanks.

[Tavian Barnes]

Guys,
       Sending mail from my local server resulted in errors "could not copy
<snip>
Aug  2 17:15:03 nirvana dovecot: imap-login: Fatal: Dovecot version
mismatch: Master is v1.2.12, login is v1.2.13 (if you don't care, set
version_ignore=yes)
Aug  2 17:15:03 nirvana dovecot: imap-login: Fatal: Dovecot version
mismatch: Master is v1.2.12, login is v1.2.13 (if you don't care, set
version_ignore=yes)
<snip>
       So I restarted dovecot -- problem solved. That brought up the
question, why didn't pacman restart dovecot with some post-install
something?? So should it have? If it didn't, does this need to be reported?

Because of KISS? Pacman is a package manager, not a system administration tool.

Imagine the story with a different daemon: SSH. You ssh into your
box, su, and pacman -Syu. Halfway through the upgrade, openssh gets
updated, which automatically restarts the server, which SIGHUPs
pacman, which is left in an inconsistent state.

       Let me know. Thanks.
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: [phone]
Facsimile: [phone]
www.rankinlawfirm.com

[J. W. Birdsong]

Post by Tavian Barnes

Guys,
       Sending mail from my local server resulted in errors "could not copy
<snip>
Aug  2 17:15:03 nirvana dovecot: imap-login: Fatal: Dovecot version
mismatch: Master is v1.2.12, login is v1.2.13 (if you don't care, set
version_ignore=yes)
Aug  2 17:15:03 nirvana dovecot: imap-login: Fatal: Dovecot version
mismatch: Master is v1.2.12, login is v1.2.13 (if you don't care, set
version_ignore=yes)
<snip>
       So I restarted dovecot -- problem solved. That brought up the
question, why didn't pacman restart dovecot with some post-install
something?? So should it have? If it didn't, does this need to be reported?

Because of KISS? Pacman is a package manager, not a system administration tool.
Imagine the story with a different daemon: SSH. You ssh into your
box, su, and pacman -Syu. Halfway through the upgrade, openssh gets
updated, which automatically restarts the server, which SIGHUPs
pacman, which is left in an inconsistent state.

       Let me know. Thanks.
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: [phone]
Facsimile: [phone]
www.rankinlawfirm.com

--
Tavian Barnes

Great point; but *we* could at least mention **Restart Dovecot with #/etc/rc.d/dovecot restart** (or some such msg) in the dovecot.install file. Because we know EVERYONE reads the pacman msg(s) after an install. Regardless I think that is the solution best hoped for. David perhaps a bug/feature request asking for same??

[Nicolas D]

Great point; but we could at least mention **Restart Dovecot with
#/etc/rc.d/dovecot restart** (or some such msg) in the dovecot.install
file. Because we know EVERYONE reads the pacman msg(s) after an
install. Regardless I think that is the solution best hoped for. David
perhaps a bug/feature request asking for same??

Why should a message be printed ?

If you've installed dovecot, and you see a dovecot update, you should know you
have to restart this service after the upgrade.

[David C. Rankin]

Post by Nicolas D

Great point; but we could at least mention **Restart Dovecot with
#/etc/rc.d/dovecot restart** (or some such msg) in the dovecot.install
file. Because we know EVERYONE reads the pacman msg(s) after an
install. Regardless I think that is the solution best hoped for. David
perhaps a bug/feature request asking for same??

Why should a message be printed ?
If you've installed dovecot, and you see a dovecot update, you should know you
have to restart this service after the upgrade.

Well sometimes the stupid ones among us don't always catch that dovecot is
being updated when it is one of 73+ updates that take place. But we 'do' always
catch the failure to copy to sent -- later :p

Seriously, one KISS thing that really works for Arch is having the little
1-line notes that are printed during update like:

<snip>
( 6/73) upgrading perl
[####################################] 100%
- The directories /usr/lib/perl5/current, /usr/lib/perl5/site_perl/current,
/usr/lib/perl5/site_perl/5.10.1, and /usr/share/perl5/site_perl/5.10.1
will be removed from @INC in a future release.
- The directory /usr/bin/perlbin/site will not be added to $PATH in a
future release.
( 7/73) upgrading enlightenment
[####################################] 100%
<snip>
(69/73) upgrading system-tools-backends
[####################################] 100%
==> Daemon method deprecated. Now is starting automatically at login
==> Remove stbd from DAEMONS list
<snip>

Having a little "** don't forget to restart dovecot" would be nice to have.

[Dieter Plaetinck]

On Tue, 03 Aug 2010 01:00:09 -0500

Post by David C. Rankin
Well sometimes the stupid ones among us don't always catch
that dovecot is being updated when it is one of 73+ updates that take
place. But we 'do' always catch the failure to copy to sent --
later :p
Seriously, one KISS thing that really works for Arch is

No useless "little 1-line notes" only ment for braindead users.. i
only want to see what i need to see.

Dieter

[Magnus Therning]

Post by Dieter Plaetinck
On Tue, 03 Aug 2010 01:00:09 -0500

      Well sometimes the stupid ones among us don't always catch
that dovecot is being updated when it is one of 73+ updates that take
place. But we 'do' always catch the failure to copy to sent --
later :p
      Seriously, one KISS thing that really works for Arch is

No useless "little 1-line notes" only ment for braindead users..  i
only want to see what i need to see.

I doubt I'm as knowledgeable on Linux systems as you, so I'd rather
like seeing a bit more messages than you need to see.

/M

[Peter Lewis]

Post by Magnus Therning

Post by Dieter Plaetinck
No useless "little 1-line notes" only ment for braindead users.. i
only want to see what i need to see.

I doubt I'm as knowledgeable on Linux systems as you, so I'd rather
like seeing a bit more messages than you need to see.

I have to admit that the recent dovecot update caught me out too for a few
minutes, until I realised that I'd had no new email for an eerie amount of
time.

But I don't think it's quite as simple as "there shouldn't be messages like
this" or that it's about "linux experience". In my experience, some packages
are affected differently than others when they are upgraded while running.

Here are three different examples in my anecdotal experience (details may be
incorrect):

- Dovecot: a running instance appears to totally break and need restarting.

- KDE: session needs restarting to run the new desktop, but the old one will
carry on running happily, possibly causing the occasional problem. Newly
launched apps are the new version (can lead to further problems).

- Firefox: everything seems fine to carry on fine. Restart the instance at
your leisure.

With a particular package, you've no idea which category this falls into.
Sure, you could apply the safest approach of always restarting everything
that's upgraded, but that's not always practical. IMO it would be nice to have
short indicators when something is likely to severely break until restarted. I
don't think that's overkill, it's just helpful.

Cheers,

Pete.

[Attila]

Post by Peter Lewis
I have to admit that the recent dovecot update caught me out too for a few
minutes, until I realised that I'd had no new email for an eerie amount of
time.

This is not nice no question but how will you solve changes in the config file
which be not backward compatible? In such a case it would be better to stop
instead of restart the daemon.

I think nothing would be better than to look what for updates be there and to
stop a daemon manual or in the case of KDE step to runlevel 3 before the update.
But this be nothing more than my 2c.

See you, Attila

[David C. Rankin]

Post by Peter Lewis
With a particular package, you've no idea which category this falls into.
Sure, you could apply the safest approach of always restarting everything
that's upgraded, but that's not always practical. IMO it would be nice to have
short indicators when something is likely to severely break until restarted. I
don't think that's overkill, it's just helpful.
Cheers,
Pete.

Dieter,

I get what you are saying and I agree. I don't want to see a multitude of
little 1-liners winking by every time I upgrade, but both Magnus and Pete have a
point. The general body of Arch users probably need to see a bit more info than
you do (no doubt I do), but Pete really puts in into context.

For those apps where an upgrade is likely to render the app broken until a
restart, then I think that a one-liner is called for to help all of us that
aren't full time devs know what packages *must* be restarted after update so
that critical apps don't remain broken until something has risen to the level of
a problem.

I look at this discussion is just a good thought process at how Arch can be
made more robust. Here setting the Arch standard for 1-liners and limiting them
to what you need to see + 1-liners for apps that will be rendered inoperative as
a result of an update just makes sense. I'm sure the list of apps that would
need 1-liners from breakage after update are less than 10 so it wouldn't add
much chatter at all to the upgrade messages. For things like MTA's, web-servers
and the like adding them would just make Arch that much better.

Maybe the Arch Santa will slip a few into his bag of presents this year. I've
been good -- I promise :p

[Andreas Radke]

Am Wed, 04 Aug 2010 00:06:53 -0500

Post by David C. Rankin

Post by Peter Lewis
With a particular package, you've no idea which category this falls
into. Sure, you could apply the safest approach of always
restarting everything that's upgraded, but that's not always
practical. IMO it would be nice to have short indicators when
something is likely to severely break until restarted. I don't
think that's overkill, it's just helpful.
Cheers,
Pete.

Dieter,
I get what you are saying and I agree. I don't want to see a
multitude of little 1-liners winking by every time I upgrade, but
both Magnus and Pete have a point. The general body of Arch users
probably need to see a bit more info than you do (no doubt I do), but
Pete really puts in into context.

You seem to want to use a distribution made safe for less skilled
users. Why do you keep wasting our time suggesting to make Arch
something it's not meant to be???

If Arch doesn't fit you needs you shouldn't use.

If package updates and restarting a daemon is hard to handle for you
should really think about this. You seem to hold the record in the last
months for silly questions about updating and using our distribution.

If you think you need a list of packages to remember where you should
interact, go on and create one your own.

-Andy

[Peter Lewis]

Hi,

Post by Andreas Radke
You seem to want to use a distribution made safe for less skilled
users. Why do you keep wasting our time suggesting to make Arch
something it's not meant to be???

I don't think that David necessarily does want this, and I hope no one will
mind mind if I say that I don't think this is really a very helpful response.
David has come to the list and asked a question, since pacman didn't behave
the way he expected it to (albeit from experience from other distros) - which
is valid.

David's original question of "why didn't/shouldn't pacman restart dovecot" has
been answered and I don't think that anyone thinks that paman should start
doing things like that.

I've learnt a reasonable amount about linux over the years, and a lot of it
has been through asking (perhaps naive) questions on mailing lists. One thing
I've learnt is that there's always someone who knows more than you and thinks
your question is trivial, and there's always someone who barely understands
what you're asking. It's not about overall world-of-warcraft-style linux skill
points, it's just about where your knowledge is focused. For example, I just
checked and I have 1394 packages installed on my laptop. I'll be damned if I
can remember the eccentricities of all of them!

Post by Andreas Radke
If Arch doesn't fit you needs you shouldn't use.

This is of course true, but in order to appreciate the beauty of a simple
distro like Arch, one has to understand *why* Arch does things the way it does
IMO. One way of doing this (of course in addition to reading the wiki etc) is
to ask around. No one individual is obliged to answer.

Post by Andreas Radke
If package updates and restarting a daemon is hard to handle for you
should really think about this. You seem to hold the record in the last
months for silly questions about updating and using our distribution.

Not helpful. See above.


WARNING: Constructive part of the post!! :-)

Post by Andreas Radke
If you think you need a list of packages to remember where you should
interact, go on and create one your own.

Absolutely, why not? If someone really wants to implement this, why not have a
flag set somewhere that tells pacman whether you want "package hints" or
something turned on. Then let packages set a one line package hint. Not for
everyone, but some people with poor memories (like me) might find it useful.

Patches welcome?

Cheers,

Pete.

[Andreas Radke]

Am Wed, 4 Aug 2010 09:22:41 +0100

Post by Peter Lewis
WARNING: Constructive part of the post!! :-)

Post by Andreas Radke
If you think you need a list of packages to remember where you
should interact, go on and create one your own.

Absolutely, why not? If someone really wants to implement this, why
not have a flag set somewhere that tells pacman whether you want
"package hints" or something turned on. Then let packages set a one
line package hint. Not for everyone, but some people with poor
memories (like me) might find it useful.
Patches welcome?
Cheers,
Pete.

Read again the Arch way: You make it what you want. We don't know if
you install a pkg like dovecot to work on its documentation, to code
stuff depending on its libs or headers or if you want to use it in
its main direction as a daemon.

Why should we make Arch more and more complex just to satisfy a few of
you with things that are almost self explaining???

If you run a daemon or application that gets upgraded it's first your
fault you didn't stop it before and 2nd your task to decide after
reading the Changelog/commit-list if you have to solve your mistake by
restarting the stuff.

-Andy

[Myra Nelson]

Post by Andreas Radke
Am Wed, 4 Aug 2010 09:22:41 +0100

Post by Peter Lewis
WARNING: Constructive part of the post!! :-)

Post by Andreas Radke
If you think you need a list of packages to remember where you
should interact, go on and create one your own.

Absolutely, why not? If someone really wants to implement this, why
not have a flag set somewhere that tells pacman whether you want
"package hints" or something turned on. Then let packages set a one
line package hint. Not for everyone, but some people with poor
memories (like me) might find it useful.
Patches welcome?
Cheers,
Pete.

Read again the Arch way: You make it what you want. We don't know if
you install a pkg like dovecot to work on its documentation, to code
stuff depending on its libs or headers or if you want to use it in
its main direction as a daemon.
Why should we make Arch more and more complex just to satisfy a few of
you with things that are almost self explaining???
If you run a daemon or application that gets upgraded it's first your
fault you didn't stop it before and 2nd your task to decide after
reading the Changelog/commit-list if you have to solve your mistake by
restarting the stuff.
-Andy

One of the things I've learned with Arch is system administration. A
talent I lost when I moved from DOS to Windows and one of the things
I've learned to dislike about most of the major Linux distros. It's
much easier to to the work when you do the install than when another
persons version of how your box is set up breaks your box. As to
making a list of things to do on upgrades, I made my own but It's only
relevant to my machines and the software I have installed. Now I'm
working on an install list and a package dependency list for all the
software (started prior to the latest pacman release that grabs the
deps for you when using makepkg). I have an extremely poor memory
that's why I made my own lists. It's up to you the user to know how to
maintain your own system.

IMHO the Arch way is great.

Now to step on some toes, both sides. Years ago I was pointed to esr's
"How to ask questions the smart way". His philosophy is excellent and
very relevant and provides many insights to developers. It took a long
time for me to realize just how annoying someone can be. It also made
me realize some of Gnome/Ubuntu's etc canned responses to filing bugs
isn't a bad idea. If someone files a bug with little or incorrect
information, they get a simple reply requesting the information they
need. Not sure that would work on a mailing list, but it might be the
way to go. It would let the user know they need to provide more info
and possibly keep the agitated responses from developers down.

I realize the developers are very busy and only work on Arch when they
have time. They don't always have time to go through the twenty
question routine of normal tech support and I appreciate that. I also
appreciate the job their doing in making Arch the best Linux distro
around. If someone were trolling, I can see an extremely tacky
response. If someone just doesn't get it, I can see an extremely tacky
response. I've seen some individuals like that on this mailing list.
That makes it easier to understand tacky responses. The best response
is the one you think about before firing away, no matter how agitated
you are. I know that for a fact. After thirty years working in the
oilfield service business, I given and received many quick agitated
responses. A lot of them to the wrong people.

Just my 2c worth.

Myra

[Jan de Groot]

Post by David C. Rankin
Well sometimes the stupid ones among us don't always catch that dovecot is
being updated when it is one of 73+ updates that take place. But we 'do' always
catch the failure to copy to sent -- later :p
Seriously, one KISS thing that really works for Arch is having the little

The point is that people don't read, so adding an update notice is not a
solution either, as people will miss that also.

[Attila]

Post by David C. Rankin
Well sometimes the stupid ones among us don't always catch that dovecot is
being updated when it is one of 73+ updates that take place. But we 'do' always
catch the failure to copy to sent -- later :p

If the count of updates is your problem than this idea could be something for
you:

# cat /etc/cron.daily/pacman.updates
#!/bin/sh
{
/usr/bin/pacman -Sy
echo
/usr/bin/pacman -Sup
} | /usr/bin/mail -s "$(hostname -s): Arch Updates" YourUser

No question, this is more simple than perfect. -)

See you, Attila

[Thomas Holmquist]

You can restart openssh without being kicked off.

Post by Tavian Barnes

Guys,
       Sending mail from my local server resulted in errors "could not copy
<snip>
Aug  2 17:15:03 nirvana dovecot: imap-login: Fatal: Dovecot version
mismatch: Master is v1.2.12, login is v1.2.13 (if you don't care, set
version_ignore=yes)
Aug  2 17:15:03 nirvana dovecot: imap-login: Fatal: Dovecot version
mismatch: Master is v1.2.12, login is v1.2.13 (if you don't care, set
version_ignore=yes)
<snip>
       So I restarted dovecot -- problem solved. That brought up the
question, why didn't pacman restart dovecot with some post-install
something?? So should it have? If it didn't, does this need to be reported?

Because of KISS? Pacman is a package manager, not a system administration tool.
Imagine the story with a different daemon: SSH. You ssh into your
box, su, and pacman -Syu. Halfway through the upgrade, openssh gets
updated, which automatically restarts the server, which SIGHUPs
pacman, which is left in an inconsistent state.

       Let me know. Thanks.
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: [phone]
Facsimile: [phone]
www.rankinlawfirm.com

--
Tavian Barnes

[David C. Rankin]

Post by Tavian Barnes
Because of KISS? Pacman is a package manager, not a system administration tool.
Imagine the story with a different daemon: SSH. You ssh into your
box, su, and pacman -Syu. Halfway through the upgrade, openssh gets
updated, which automatically restarts the server, which SIGHUPs
pacman, which is left in an inconsistent state.

Thanks,

That's all I needed to know. I'll keep a closer eye on the logs after update.
My post wasn't to imply that pacman 'should' do it, it was just meant as a query
of if it 'was' supposed to do it, it didn't :p

I agree with the philosophy of having pacman NOT do it for any packages. There
is brilliance in KISS. Once a few packages 'start' doing it, then there is a
continual open question in users minds "Does package X have a post-install that
does it -- or not?"

[Jan de Groot]

Post by Tavian Barnes
Imagine the story with a different daemon: SSH. You ssh into your
box, su, and pacman -Syu. Halfway through the upgrade, openssh gets
updated, which automatically restarts the server, which SIGHUPs
pacman, which is left in an inconsistent state.

OpenSSH is designed to keep its connection alive during restarts. You
can even stop sshd without losing connection, as long as the rc.d script
is not buggy (we had a buggy script that would kill all child processes
too a while ago...)

[Tavian Barnes]

Post by Jan de Groot

Imagine the story with a different daemon: SSH.  You ssh into your
box, su, and pacman -Syu.  Halfway through the upgrade, openssh gets
updated, which automatically restarts the server, which SIGHUPs
pacman, which is left in an inconsistent state.

OpenSSH is designed to keep its connection alive during restarts. You
can even stop sshd without losing connection, as long as the rc.d script
is not buggy (we had a buggy script that would kill all child processes
too a while ago...)

Huh, I did not know that, cool. Still, the example works if you
replace ssh with some hypothetical service that doesn't gracefully
handle restarts. Or the worse case where the restart fails and you
only notice 4 days later.

[Attila]

Post by Tavian Barnes
Because of KISS? Pacman is a package manager, not a system administration tool.

This has nothing to do with package manager or not because dpkg or rpm can do
this without a problem.

Post by Tavian Barnes
Imagine the story with a different daemon: SSH. You ssh into your
box, su, and pacman -Syu. Halfway through the upgrade, openssh gets
updated, which automatically restarts the server, which SIGHUPs
pacman, which is left in an inconsistent state.

I have never had problems with a ssh session if i update ssh on my opensuse
server and the specfile has this inside:

%postun
%restart_on_update sshd
%{insserv_cleanup}

It is okay if you say KISS is the goal but inside of a *.install file you could
do the same as in a specfile of a rpm package and no one would call rpm a
"system administration tool".-)

And before one of the arch devs could misunderstood my lines: I can live
perfectly that we the users do this by ourselves instead that the packaging
comsumes more and more time.

See you, Attila

[Ng Oon-Ee]

Post by David C. Rankin
Guys,
Sending mail from my local server resulted in errors "could not copy sent mail
<snip>
Master is v1.2.12, login is v1.2.13 (if you don't care, set version_ignore=yes)
Master is v1.2.12, login is v1.2.13 (if you don't care, set version_ignore=yes)
<snip>
So I restarted dovecot -- problem solved. That brought up the question, why
didn't pacman restart dovecot with some post-install something?? So should it
have? If it didn't, does this need to be reported?
Let me know. Thanks.

Just because I have dovecot installed doesn't mean its running at the
point I do the update. I'd think the responsibility is with the user to
do what is necessary. In the end its up to the packager though.

[Attila]

Okay, i recognized that i wrote too much under this little thread so set it on
read if this is too much for you.-)

The best compromise what i have seen is what zypper (package management tool for
opensuse) do in a case if libs or a daemon get changed.

After upgrading in such a case you get a warning that some apps point to deleted
files and that with a "zypper ps" you can get the list of them. The list itselfs
looks like this (from my memory):

PID | user | file | libs
101 | user1 | app1 | PATH/lib21.so.21
| | | PATH/lib22.so.22
99 | daemon | daemon | PATH/lib11.so.11
| | | PATH/lib11.so.11
201 | root | app2 | PATH/lib31.so.31
| | | PATH/lib31.so.31

So the nice thing is that you even know if a logout or a restart of a daemon or
a reboot solves it. And the best is that you get the information not as the
output of the 73'st package from 125 packages, you get it at the end where the
attention could (or should be) the best.

I don't know if the rpm database helps here more than the one from pacman or how
this is realised. But at the end the most important point (which is even valid):
The question is even how much is the effort to realize such a "luxury" solution
and is it this worth. That is why i never wrote a feature request instead i
think this idea is very nice.-)

See you, Attila

[Heiko Baums]

Am Tue, 03 Aug 2010 21:40:20 +0200

Post by Attila
Okay, i recognized that i wrote too much under this little thread so
set it on read if this is too much for you.-)
...

I must admit, that I didn't read this completely.

It's so simple and every Linux user should or must know this. If a
daemon or any other software is updated it must be restarted either to
use the new version or to get it working if the running version broken
by the update. And the config files need to be checked and customized
after every update.

That's a common and necessary task of a Linux admin which doesn't need
and in my opinion shouldn't be done by the package manager, because the
package manager can't decide which config files I need or want to
adjust and when I can and want to restart which daemon. Restarting
daemons automatically by the package manager can break a lot and can do
a lot more harm.

And there are definitely no messages from the package manager needed.

Just KISS and just a common and usual work of an admin. It just belongs
to the basic knowledge.

If a production server is updated then the users have to be informed
before the update.

Heiko

[f***@kokkinizita.net]

Post by Heiko Baums
It's so simple and every Linux user should or must know this. If a
daemon or any other software is updated it must be restarted either to
use the new version or to get it working if the running version broken
by the update. And the config files need to be checked and customized
after every update.
That's a common and necessary task of a Linux admin which doesn't need
and in my opinion shouldn't be done by the package manager, because the
package manager can't decide which config files I need or want to
adjust and when I can and want to restart which daemon. Restarting
daemons automatically by the package manager can break a lot and can do
a lot more harm.

I agree,

Post by Heiko Baums
And there are definitely no messages from the package manager needed.

Well, that depends. If a user is upgrading a package X explicitly then
he/she is probably anticipating the consequences, and has prepared for
them. If X is updated as a side effect that could be different, and a
warning would be good thing.

Post by Heiko Baums
Just KISS and just a common and usual work of an admin. It just belongs
to the basic knowledge.

Again agreed. But some changes are quite invasive. Going from Xorg 1.7
to 1.8 without being prepared for it can hit you where it hurts. It
happened to me just a few days ago (all is OK now).

Ciao,

[Heiko Baums]

Am Tue, 3 Aug 2010 22:48:48 +0200

Post by f***@kokkinizita.net
Well, that depends. If a user is upgrading a package X explicitly then
he/she is probably anticipating the consequences, and has prepared for
them. If X is updated as a side effect that could be different, and a
warning would be good thing.

Before the system is updated by `pacman -Syu` pacman shows you every
package which will be updated and asks you if you really want to
update. If someone is too lazy to read this list it's his own problem.

And I doubt that someone who is too lazy to read pacman's package list
will read the post install messages.

Nevertheless such messages are not necessary because it's just basic
knowledge and every Linux admin must know that daemons have to be
restarted after updating. It's even better to stop the daemon before
it's upgraded.

Post by f***@kokkinizita.net
Again agreed. But some changes are quite invasive. Going from Xorg 1.7
to 1.8 without being prepared for it can hit you where it hurts. It
happened to me just a few days ago (all is OK now).

I had no problem with the X upgrade. But I read the news on the
homepage before I updated it. ;-) This explained everything I needed to
know.

Well, of course, every update can break something, but usually it's not
a big issue. I'm using Linux since several years now, even if I'm still
not omniscient, first SuSE, then Gentoo, now Arch Linux, and I never
had any serious breakages. I even didn't made any backups of my old
kernels before a kernel update. And I never had a problem with a kernel
update.

Well, I once had one serious issue but that was totally my fault, but I
knew that this could happen before I did what I did. So not an issue at
all.

Heiko

[Mario Figueiredo]

Post by Heiko Baums
Am Tue, 03 Aug 2010 21:40:20 +0200
It's so simple and every Linux user should or must know this. If a
daemon or any other software is updated it must be restarted either to
use the new version or to get it working if the running version broken
by the update. And the config files need to be checked and customized
after every update.
That's a common and necessary task of a Linux admin which doesn't need
and in my opinion shouldn't be done by the package manager, because the
package manager can't decide which config files I need or want to
adjust and when I can and want to restart which daemon. Restarting
daemons automatically by the package manager can break a lot and can do
a lot more harm.

An argument can be made that this approach makes a rolling release less
attractive to users who have invested heavily in the supported
repositories. I heard this much just recently from a former Arch user;
The possibility of an an unpdate resulting in a post-update maintenance
nightmare to get the machine up and running again can be a little scary.

But I do agree with you. I just don't think that waving the KISS
principle as a weapon achieves much. It's a tool. And it has its
disadvantages. Users must be aware of them.

If a user keeps the machine updated regularly and follows a tight
upgrade schedule, they will have to deal with only minor incidents once
and a while. And all easy to handle. Stop daemon, start daemon. On the
other hand, if a user decides to update their machine once every two
months, they must understand that it is not the rolling release system
that is at fault. It's them for not understanding what's the point of a
rolling release.

[Heiko Baums]

Am Tue, 03 Aug 2010 21:59:10 +0100

Post by Mario Figueiredo
An argument can be made that this approach makes a rolling release
less attractive to users who have invested heavily in the supported
repositories. I heard this much just recently from a former Arch
user; The possibility of an an unpdate resulting in a post-update
maintenance nightmare to get the machine up and running again can be
a little scary.

I hadn't had any post-update maintenance nightmares yet. Well, not
nightmares. I want to know what is done and what happens on my system.
Otherwise I would recommend a different distro. But to be honest I had
a lot more post-update nightmares with SuSE, because YaST has always
overridden my configurations. This can't happen with Arch due to
the .pacnew files.

And I don't think `diff configfile configfile.pacnew` and an
`/etc/rc.d/daemon restart` is such a nightmare.

Arch is only scary if people don't want to learn Linux and read
documentations. There are better distros for those people.

Post by Mario Figueiredo
But I do agree with you. I just don't think that waving the KISS
principle as a weapon achieves much. It's a tool. And it has its
disadvantages. Users must be aware of them.

But with KISS you have the most control over your system. Well, there
can be a few exceptions if they make sense. But this is not the case
for daemon restarting.

Post by Mario Figueiredo
If a user keeps the machine updated regularly and follows a tight
upgrade schedule, they will have to deal with only minor incidents
once and a while. And all easy to handle. Stop daemon, start daemon.
On the other hand, if a user decides to update their machine once
every two months, they must understand that it is not the rolling
release system that is at fault. It's them for not understanding
what's the point of a rolling release.

I totally agree.

Heiko

[Attila]

Post by Heiko Baums
I hadn't had any post-update maintenance nightmares yet. Well, not
nightmares. I want to know what is done and what happens on my system.
Otherwise I would recommend a different distro. But to be honest I had
a lot more post-update nightmares with SuSE, because YaST has always
overridden my configurations. This can't happen with Arch due to
the .pacnew files.

Only for the stats: In the case of updating packages Yast, and im suprised that
you use this more than zypper, don't touch changed config files because
opensuse, and every other rpm basesd distribution, do the same as archlinux with
*.rpmsave and *.rpmnew files.

As i said in the other posting, i don't think that any packager on this planet
do mistakes with intent but they be even possible because we are all only
humans. -)

See you, Attila

[Heiko Baums]

Am Wed, 04 Aug 2010 07:14 +0200

Post by Attila
Only for the stats: In the case of updating packages Yast, and im
suprised that you use this more than zypper, don't touch changed
config files because opensuse, and every other rpm basesd
distribution, do the same as archlinux with *.rpmsave and *.rpmnew
files.

I'm not using openSUSE anymore. I used SuSE several years ago when
there was only YaST and YaST2. So I don't know zypper.

I admit that this comment was a little bit unfair on openSUSE. But
I've written SuSE and it was my experience with it. ;-)

Heiko

[Attila]

Post by Mario Figueiredo
An argument can be made that this approach makes a rolling release less
attractive to users who have invested heavily in the supported
repositories. I heard this much just recently from a former Arch user;
The possibility of an an unpdate resulting in a post-update maintenance
nightmare to get the machine up and running again can be a little scary.

I don't think that the principle of rolling releases support such mistakes more
than as you use another distribution. You only move the timepoint more in the
future but if such a distribution do the step from at example A to B than you
have to do this "nightmare" search of changed config files for all packages.

That's all because mistakes are even possible instead no one wants to make them.
I think, and this is more my experience, that you will get a lot of more stories
about updates in archlinux which runs without a problem instead the list of
packages was enormous.

See you, Attila

[Attila]

Post by Heiko Baums
That's a common and necessary task of a Linux admin which doesn't need
and in my opinion shouldn't be done by the package manager, because the
package manager can't decide which config files I need or want to
adjust and when I can and want to restart which daemon. Restarting
daemons automatically by the package manager can break a lot and can do
a lot more harm.

Here i'm be with you but this problem with restarting daemons has more to do
that we all enjoy this rolling releases under archlinux. In a case of a
distribution which does this not you can do this without a problem in a lot of
cases.

Post by Heiko Baums
And there are definitely no messages from the package manager needed.

Before i saw this feature with the warning in zypper i would say here yes too
but now i found this very useful because in the case of gui apps or the gui
itself it is not even clear for me what for libs been used. I'm running opensuse
on my laptop too and i'm often suprised after an update what for litte apps use
what for libs.

But no question, it would more say it is nice if it is there but not a thing
what is absolutely necessary or that it is unacceptable that we users do this by
ourselves.

See you, Attila

[Guus Snijders]

[...]

Post by Attila
Before i saw this feature with the warning in zypper i would say here
yes too but now i found this very useful because in the case of gui
apps or the gui itself it is not even clear for me what for libs been
used. I'm running opensuse on my laptop too and i'm often suprised
after an update what for litte apps use what for libs.
But no question, it would more say it is nice if it is there but not
a thing what is absolutely necessary or that it is unacceptable that
we users do this by ourselves.

Well, you certainly do have a point; finding out which apps are using
the updated libraries etc would be nice.
After thinking about it for a moment, it seems one solution would be
very simple. Just run "lsof | grep -i DEL".
I'm pretty sure that this could be much optimized, but i hope the idea
is clear.

System administration is all about taking responsibility, IMHO.

When it gets too hard for some users, they could always consider rebooting.

HTH, HAND


mvg,
Guus

[Attila]

Post by Guus Snijders
Well, you certainly do have a point; finding out which apps are using
the updated libraries etc would be nice.

Here is a example of the output and what it is behind:

http://www.kriyayoga.com/love_blog/post.php/1207

How more i search in the web what is behind i found out that it seems that
"zypper ps" run this only for the list of the updated packages and not for the
whole system. This makes it very hard for myself to find out how i can get the
same under archlinux.

Post by Guus Snijders
After thinking about it for a moment, it seems one solution would be
very simple. Just run "lsof | grep -i DEL".

It seems that you don't use KDE because i get a big list of '*kdelibs*'
entries.-)

One other human used this "lsof -n | grep -E 'RPMDELETE|;|path inode='" under
opensuse before zypper get this feature. But RPMDELETE won't be there under
archlinux.

Post by Guus Snijders
I'm pretty sure that this could be much optimized, but i hope the idea
is clear

If you find something for this this would be very, very nice.-)

See you, Attila

[Guus Snijders]

[ list of apps to restart after update ]

Post by Attila

Post by Guus Snijders
After thinking about it for a moment, it seems one solution would
be very simple. Just run "lsof | grep -i DEL".

It seems that you don't use KDE because i get a big list of
'*kdelibs*' entries.-)

In that case, try:
lsof | grep " DEL "

Note the spaces before and after DEL.
After checking it again, i noted that lsof uses caps for the type, so we
can drop the -i from grep.

But you were right, i didn't think of kdelibs. ;)


mvg,
Guus

[Attila]

Post by Guus Snijders
lsof | grep " DEL "
Note the spaces before and after DEL.
After checking it again, i noted that lsof uses caps for the type, so we
can drop the -i from grep.

This idea is better and now i have to wait for an update which will use deleted
files.

Only for the stast it is not unusually that apps use deleted files:

# lsof -n | grep ' DEL '
firefox 1832 arpad DEL REG 0,4 1998849 /SYSV00000000
kwin 3815 arpad DEL REG 0,4 0 /SYSV00000000

The way of an rpm based system with using RPMDELETE as the flag seems easier to
find out such files. Is there a analog way possible for pacman? I never take a
look after an update with pacman.

See you, Attila

[Attila]

Post by Guus Snijders
lsof | grep " DEL "

Okay, with the update of util-linux-ng checking of the deleted files makes sense
because a lot of files use /lib/libuuid.so.1.3.0. I create this MINI script for
this:

# cat /usr/local/bin/scan_deleted_files.sh
#!/bin/sh
# list of deleted files

echo 'COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME'
lsof -n | grep ' DEL '

See you, Attila

[Loui Chang]

Post by Guus Snijders
HTH, HAND

What?

[Gary Wright]

Post by Guus Snijders
HTH, HAND

What?

HTH[1] HAND[2]

[1] http://www.acronymfinder.com/HtH.html
[2] http://www.acronymfinder.com/HAND.html

[Jeffrey Lynn Parke Jr.]

Post by Gary Wright

Post by Guus Snijders
HTH, HAND

What?

HTH[1] HAND[2]
[1] http://www.acronymfinder.com/HtH.html
[2] http://www.acronymfinder.com/HAND.html

now we are just getting lazy

[Loui Chang]

Post by Gary Wright

Post by Guus Snijders
HTH, HAND

What?

HTH[1] HAND[2]
[1] http://www.acronymfinder.com/HtH.html
[2] http://www.acronymfinder.com/HAND.html

Bah thanks.
Bloody Hell. Can we not write in English?
I think that sort of thing is more appropriate on AOL chat.