[arch-general] Fix or not fix? install scriptlets with user handling.

Gerardo Exequiel Pozzi

27 May 2009 27 May '09

7:58 p.m.

Hi, Many package manage user/groups in many differents ways. (no much problem here) Many do things like: @ when installed 1) check if not user foo exists then create it 2) check if not group foo exists then create it @when removed 1) remove the user foo (without check) 2) remove the group foo (without check) Because by default the option USERGROUPS_ENAB is set to yes, when user "foo" is removed also the group "foo" is removed, so the groupdel command will fail, then pacman show the message: "error: scriptlet failed to execute correctly". The solution is trivial, check with getent before remove, just like some packages do it before create the user. My question here, is there interest in resolving this? Currently I have the choice of those who fail (both extra and comunity). Do you send a report to everyone who fail to flyspray with the patch (low priority)? Also I can unify the user creation step, some .install check with "grep" and others with "getent". I prefer the proper getent method. The only package in [core] that have this issue is dbus-core [#1] and is actually reported. [#1] http://bugs.archlinux.org/task/14810 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Show replies by date

Damjan Georgievski

27 May 27 May

9:24 p.m.

...

Many package manage user/groups in many differents ways. (no much problem here)

Many do things like:

@ when installed 1) check if not user foo exists then create it 2) check if not group foo exists then create it @when removed 1) remove the user foo (without check) 2) remove the group foo (without check)

Because by default the option USERGROUPS_ENAB is set to yes, when user "foo" is removed also the group "foo" is removed, so the groupdel command will fail, then pacman show the message: "error: scriptlet failed to execute correctly".

The solution is trivial, check with getent before remove, just like some packages do it before create the user.

My question here, is there interest in resolving this? Currently I have the choice of those who fail (both extra and comunity). Do you send a report to everyone who fail to flyspray with the patch (low priority)? Also I can unify the user creation step, some .install check with "grep" and others with "getent". I prefer the proper getent method.

Maybe PKGBUILD could have a user[s] and group[s] variables that only specify the user/group needed for the package and pacman could take care of the actual creating and removing of the user and group? .. just an idea -- damjan

Gerardo Exequiel Pozzi

9:32 p.m.

New subject: [arch-general] Fix or not fix? install scriptlets with user handling.

Damjan Georgievski wrote:

...

...
Many package manage user/groups in many differents ways. (no much problem here)

Maybe PKGBUILD could have a user[s] and group[s] variables that only specify the user/group needed for the package and pacman could take care of the actual creating and removing of the user and group?

.. just an idea

Hi Yes, this is in TODO for some time in the future. See here http://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database But at this moment, this is not implemented, so... my question is... fix or not? I can do it, no problem. Good Luck! -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

ludovic coues

28 May 28 May

9:14 a.m.

It's just matter of few line in a PKGBUILD, isn't it ? For my, it should be ask for packager to fix it for the next upgrade. And a work on the UID / GID database is the solution for me. Maybe it might be better to work on this rather than fix every PKGBUILD.

RedShift

9:28 a.m.

New subject: [arch-general] Fix or not fix? install scriptlets with user handling.

Gerardo Exequiel Pozzi wrote:

...

Hi,

Many package manage user/groups in many differents ways. (no much problem here)

Many do things like:

@ when installed 1) check if not user foo exists then create it 2) check if not group foo exists then create it @when removed 1) remove the user foo (without check) 2) remove the group foo (without check)

Because by default the option USERGROUPS_ENAB is set to yes, when user "foo" is removed also the group "foo" is removed, so the groupdel command will fail, then pacman show the message: "error: scriptlet failed to execute correctly".

The solution is trivial, check with getent before remove, just like some packages do it before create the user.

My question here, is there interest in resolving this? Currently I have the choice of those who fail (both extra and comunity). Do you send a report to everyone who fail to flyspray with the patch (low priority)? Also I can unify the user creation step, some .install check with "grep" and others with "getent". I prefer the proper getent method.

The only package in [core] that have this issue is dbus-core [#1] and is actually reported.

[#1] http://bugs.archlinux.org/task/14810

Hi IMNSHO .install scripts should never ever add users or groups, let alone remove them. Everything that would need a user for itself should default to "nobody". Yes, this imposes, though small, a security risk but any decent server admin will move that stuff to its own user. I've even seen packages that start and stop daemons themselves (shrug!), if it were up to me there would be no such things. But many believe that automatically adding and removing users is "OK". A package should install its program files, and THAT'S IT. Nothing more. It may be a bit a spartan way, but it's reliable (no unexpected surprises) and leads to an uncluttered passwd and group file. Glenn

Jan de Groot

9:46 a.m.

New subject: [arch-general] Fix or not fix? install scriptlets with user handling.

On Thu, 2009-05-28 at 11:28 +0200, RedShift wrote:

...

IMNSHO .install scripts should never ever add users or groups, let alone remove them. Everything that would need a user for itself should default to "nobody". Yes, this imposes, though small, a security risk but any decent server admin will move that stuff to its own user.

I've even seen packages that start and stop daemons themselves (shrug!), if it were up to me there would be no such things. But many believe that automatically adding and removing users is "OK". A package should install its program files, and THAT'S IT. Nothing more. It may be a bit a spartan way, but it's reliable (no unexpected surprises) and leads to an uncluttered passwd and group file.

Running everything with the nobody group means that the nobody user will become another superuser. This is a very bad idea. With your "solution", programs that install setuid/setgid files such as policykit become dangerous to install.

ludovic coues

3:09 p.m.

A solution in pacman, getting rid of user adding in .install script, can allow security like asking user to confirm creation of group and user. This would be a secure way of doing thing, and users/admin would be aware of new user/group. And like glenn, I'm wondering how package can add or remove daemon. These are users set, and when are ok, need no worries. If package add/remove them, it's unexpected problem coming to the user.

Jan Spakula

4:18 p.m.

Excerpts from ludovic coues's message of Do Mai 28 17:09:52 +0200 2009:

...

A solution in pacman, getting rid of user adding in .install script, can allow security like asking user to confirm creation of group and user.

This would be a secure way of doing thing, and users/admin would be aware of new user/group.

I don't get how is adding/removing users/groups from pacman directly safer then doing the same from the install script. How about just *informing* the user what's happening in the install script? Then there would be no 'unexpected behavior'.

ludovic coues

4:47 p.m.

That 2009/5/28, Jan Spakula :

...

Excerpts from ludovic coues's message of Do Mai 28 17:09:52 +0200 2009:

...
A solution in pacman, getting rid of user adding in .install script, can allow security like asking user to confirm creation of group and user.

This would be a secure way of doing thing, and users/admin would be aware of new user/group.

I don't get how is adding/removing users/groups from pacman directly safer then doing the same from the install script.

How about just *informing* the user what's happening in the install script? Then there would be no 'unexpected behavior'.

That's what I want to when I suggest to confirm the creation. And pacman can have some internal security that can be by-pass if some PKGBUILD field are used. For example, pacman could have a database with which app have add which user, and will not remove a user which is needed by an app when another app want remove it on uninstall.

Jan de Groot

4:53 p.m.

New subject: [arch-general] Fix or not fix? install scriptlets with user handling.

On Thu, 2009-05-28 at 18:47 +0200, ludovic coues wrote:

...

That

2009/5/28, Jan Spakula :

...
Excerpts from ludovic coues's message of Do Mai 28 17:09:52 +0200 2009:

...
A solution in pacman, getting rid of user adding in .install script, can allow security like asking user to confirm creation of group and user.

This would be a secure way of doing thing, and users/admin would be aware of new user/group.

I don't get how is adding/removing users/groups from pacman directly safer then doing the same from the install script.

How about just *informing* the user what's happening in the install script? Then there would be no 'unexpected behavior'.

That's what I want to when I suggest to confirm the creation. And pacman can have some internal security that can be by-pass if some PKGBUILD field are used. For example, pacman could have a database with which app have add which user, and will not remove a user which is needed by an app when another app want remove it on uninstall.

Packages shouldn't share user accounts usually, and in case they do, they should be in the filesystem package. As for (re)starting daemons: don't. It's up to the user to do that. Usually these things need configuration, it's a no-go to add them to rc.conf by default.

ludovic coues

5:01 p.m.

I'm agree with that. Bug report should be filed for operation on daemon in .install script. 2009/5/28, Jan de Groot :

...

On Thu, 2009-05-28 at 18:47 +0200, ludovic coues wrote:

...
That

2009/5/28, Jan Spakula :

...
Excerpts from ludovic coues's message of Do Mai 28 17:09:52 +0200 2009:

...
A solution in pacman, getting rid of user adding in .install script, can allow security like asking user to confirm creation of group and user.

This would be a secure way of doing thing, and users/admin would be aware of new user/group.

I don't get how is adding/removing users/groups from pacman directly safer then doing the same from the install script.

How about just *informing* the user what's happening in the install script? Then there would be no 'unexpected behavior'.

That's what I want to when I suggest to confirm the creation. And pacman can have some internal security that can be by-pass if some PKGBUILD field are used. For example, pacman could have a database with which app have add which user, and will not remove a user which is needed by an app when another app want remove it on uninstall.

Packages shouldn't share user accounts usually, and in case they do, they should be in the filesystem package.

As for (re)starting daemons: don't. It's up to the user to do that. Usually these things need configuration, it's a no-go to add them to rc.conf by default.

Attila

9:33 p.m.

On Donnerstag, 28. Mai 2009 18:53 Jan de Groot wrote:

...

Packages shouldn't share user accounts usually, and in case they do, they should be in the filesystem package.

The most here speaks about the technical side but from my view there is a humanly side too. If you put all static in the filesystem package than you have to document it and you never have to forget it to keep it up to date which is not realistic because we all be only humans. The most other distributions creates user/groups during installing a package and so i'm a little bit surprised that you don't want to do the same.

...

As for (re)starting daemons: don't. It's up to the user to do that. Usually these things need configuration, it's a no-go to add them to rc.conf by default.

Definitely +1 for don't starting. But -1 for don't restarting because it is the job of a package management to guarantee that an upgrade is safe and if a daemon needs to restart than doing this is better as doing nothing. See you, Attila

Daenyth Blank

10:03 p.m.

On Thu, May 28, 2009 at 17:33, Attila wrote:

...

But -1 for don't restarting because it is the job of a package management to guarantee that an upgrade is safe and if a daemon needs to restart than doing this is better as doing nothing.

See you, Attila

-1. Restarting it automatically is also bad. If it's currently stopped, restarting it will still start it, and the user may not want it stopped at all (which restarting it would do).

Johannes Held

11:34 p.m.

New subject: [arch-general] Fix or not fix? install scriptlets with user handling.

I'm not really an expert on this topic... but could it be a solution to ask the user in a pre-install step? Like: This update will change many things in the config and does this and that and some other bad things. It's recommended that the service FOO is restarted after update. Should I restart it for you? [Y,n] -- Gruß, Johannes Täglich http://blog.hehejo.de und du fühlst dich gut. Mast und Schotbruch mit dem http://segelsport-blog.de.

Daenyth Blank

11:47 p.m.

On Thu, May 28, 2009 at 19:34, Johannes Held wrote:

...

I'm not really an expert on this topic...

but could it be a solution to ask the user in a pre-install step? Like: This update will change many things in the config and does this and that and some other bad things. It's recommended that the service FOO is restarted after update. Should I restart it for you? [Y,n]

I don't really see how this is needed. If a user updates package X which he knows is running a daemon, it's not hard to know whether or not it should be restarted. We should always assume the user is competant

Giovanni Scafora

11:52 p.m.

2009/5/28, Daenyth Blank :

...

I don't really see how this is needed. If a user updates package X which he knows is running a daemon, it's not hard to know whether or not it should be restarted. We should always assume the user is competant

+1 Here, I am fine with Daenyth. -- Arch Linux Developer http://www.archlinux.org

Gerardo Exequiel Pozzi

29 May 29 May

12:08 a.m.

New subject: [arch-general] Fix or not fix? install scriptlets with user handling.

Giovanni Scafora wrote:

...

2009/5/28, Daenyth Blank :

...
I don't really see how this is needed. If a user updates package X which he knows is running a daemon, it's not hard to know whether or not it should be restarted. We should always assume the user is competant

+1 Here, I am fine with Daenyth.

Exacto :) Personally when I do the upgrades, i take care about what is upgraded. And after upgrade i have an alias to view what is needed to reload. alias lsof-deletes='lsof -n | grep -e "deleted" -e "DEL" | grep -v -e " /dev/" -e " /SYSV" -e " /var/tmp/" -e " /tmp/"' sometimes (for example glibc) I prefer to do "pacman -Sywu; init 1" then login killall syslog-ng udevd; pacman -Su start udevd and go againt to init 3. My two cents. PS: The original topic was for user handling. So maybe i will post the fixes for each package that "shows fails" on remove. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Johannes Held

28 May 28 May

11:54 p.m.

New subject: [arch-general] Fix or not fix? install scriptlets with user handling.

...

I don't really see how this is needed. If a user updates package X which he knows is running a daemon, it's not hard to know whether or not it should be restarted. We should always assume the user is competant Yes, that's right. But it would fix the problem of "should every daemon of this

Daenyth Blank : package be restarted or not?". If the user stopped a deamon, he would say "no" to the question and the deamon will remain stopped. -- Gruß, Johannes Täglich http://blog.hehejo.de und du fühlst dich gut. Mast und Schotbruch mit dem http://segelsport-blog.de.

Grigorios Bouzakis

29 May 29 May

12:04 a.m.

New subject: [arch-general] Fix or not fix? install scriptlets with user handling.

On Fri, May 29, 2009 at 01:54:45AM +0200, Johannes Held wrote:

...

...
I don't really see how this is needed. If a user updates package X which he knows is running a daemon, it's not hard to know whether or not it should be restarted. We should always assume the user is competant Yes, that's right. But it would fix the problem of "should every daemon of this

Daenyth Blank : package be restarted or not?".

If the user stopped a deamon, he would say "no" to the question and the deamon will remain stopped.

I don't see the issue you refer to as "problem". If you are serious about it: http://projects.archlinux.org/?p=pacman.git;a=summary Its a pacman issue. -- Greg

Frédéric Perrin

12:02 a.m.

Le Vendredi 29 à 1:47, Daenyth Blank a écrit :

...

I don't really see how this is needed. If a user updates package X which he knows is running a daemon, it's not hard to know whether or not it should be restarted. We should always assume the user is competant

When PAM is updated, sshd may need to be restarted. Other dependencies may not be as obvious. The user is compentent != The user knows precisely which daemon needs a restart after another lib update, or has time to track all such dependencies. -- Fred

Frédéric Perrin

28 May 28 May

11:56 p.m.

Hello, Le Vendredi 29 à 0:03, Daenyth Blank a écrit :

...

On Thu, May 28, 2009 at 17:33, Attila wrote:

...
But -1 for don't restarting because it is the job of a package management to guarantee that an upgrade is safe and if a daemon needs to restart than doing this is better as doing nothing.

-1. Restarting it automatically is also bad. If it's currently stopped, restarting it will still start it, and the user may not want it stopped at all (which restarting it would do).

I'm just an user, but... if I ask the service to be restarted when it is not started yet, I would expect the rc script to fail as early and loudly as possible, no ? Somebody suggested interactively asking the user about restarting the service, it means more babysitting of the upgrade process which is bad. A big warning message "You should restart service $FOO when you are done updating" is good. Even better, all such messages could be displayed at the end of the upgrade process, so that they are not lost in the middle of the normal progress indicators. Juste my €0.02. -- Fred

Attila

29 May 29 May

5:12 a.m.

On Freitag, 29. Mai 2009 00:03 Daenyth Blank wrote:

...

-1. Restarting it automatically is also bad. If it's currently stopped, restarting it will still start it, and the user may not want it stopped at all (which restarting it would do).

If the user don't want that a daemon get restarted than he/she can solve this by not upgrading this package in this moment and do it it later. The question is more what do you have from a new update on the harddisk but you runs the old one in the memory. And if you have fear that a new config will be a problem than you only defer this problem to the next reboot and risk that the user can't remember why it happens that the daemon don't start. I'm a little bit surprised that on the one side you think that the user is competent enough to recognize that a *.pacnew file have to be merged with his config and on the other side you think he/she is too incompetent to recognize why the restart of his daemon fails after the update. So therefore from my view restarting has more advantages than doing nothing. See you, Attila

Xavier

6:20 a.m.

On Fri, May 29, 2009 at 7:12 AM, Attila wrote:

...

I'm a little bit surprised that on the one side you think that the user is competent enough to recognize that a *.pacnew file have to be merged with his config and on the other side you think he/she is too incompetent to recognize why the restart of his daemon fails after the update.

The restart of the daemon could fail because the config file has not been updated yet with the .pacnew one. It might not be a good idea to restart the daemon automatically without checking the config first. In any cases, this is not something that you can control globally. It has to be handled separately in every install scriptlet of daemon packages. Also keep that in mind.

Daenyth Blank

10:17 a.m.

On Fri, May 29, 2009 at 02:20, Xavier wrote:

...

The restart of the daemon could fail because the config file has not been updated yet with the .pacnew one. It might not be a good idea to restart the daemon automatically without checking the config first.

In any cases, this is not something that you can control globally. It has to be handled separately in every install scriptlet of daemon packages. Also keep that in mind.

I don't see why pacman has to handle this at all. I've never heard of anyone having a problem with this situation, ever. Let's not add features unless there's a real need for them.

Attila

3:42 p.m.

On Freitag, 29. Mai 2009 08:20 Xavier wrote:

...

The restart of the daemon could fail because the config file has not been updated yet with the .pacnew one. It might not be a good idea to restart the daemon automatically without checking the config first.

I'm be with you that the config has to be changed or at minimum controlled first but if a restart will fails (case 1) than it will fails at the next reboot too (case 2) and i don't see any reason why case 1 is so much more important as case 2. And still again i suggest to take a look at other distros where daemons get restarted without a problem during a upgrade procedure. Sorry, but i find this rule of "don't restart during the upgrade" a little bit academically.-)

...

In any cases, this is not something that you can control globally. It has to be handled separately in every install scriptlet of daemon packages. Also keep that in mind.

Absoulutely +1 and i say only my opinion about the same thing. See you, Attila

Jan Spakula

30 May 30 May

7:41 a.m.

Excerpts from Attila's message of Fr Mai 29 17:42:23 +0200 2009:

...

And still again i suggest to take a look at other distros where daemons get restarted without a problem during a upgrade procedure. Sorry, but i find this rule of "don't restart during the upgrade" a little bit academically.-)

For me it's about 'expectations'. I expect a package manager to manage packages (unpack a new one over the old one in a sensible manner) and don't expect it to decide what's best for me in terms of what's running or not. I still find it 100% better to *let me know* that config might have changed (pacman does this automatically) and that something might need to be done if, say, I run this and that daemon. Don't run it for me. And if you absolutely have to, *let me know*. -- Jan

ludovic coues

9:28 a.m.

...

For me it's about 'expectations'. I expect a package manager to manage packages (unpack a new one over the old one in a sensible manner) and don't expect it to decide what's best for me in terms of what's running or not. I still find it 100% better to *let me know* that config might have changed (pacman does this automatically) and that something might need to be done if, say, I run this and that daemon. Don't run it for me. And if you absolutely have to, *let me know*.

-- Jan

Maybe that a PKGBUILD runned solution, could allow to set some pacman's config for this. Like a field " auto-restart_daemon = 1", wich you can set to 0, if you don't want. Same for adding user. If the field is to 1, pacman manage it by itself, if it's set to 0, pacman just print warning informing the user that he need to apply change to the daemon, i.e. restart it.

Daenyth Blank

11:54 a.m.

On Sat, May 30, 2009 at 05:28, ludovic coues wrote:

...

Maybe that a PKGBUILD runned solution, could allow to set some pacman's config for this. Like a field " auto-restart_daemon = 1", wich you can set to 0, if you don't want. Same for adding user.

If the field is to 1, pacman manage it by itself, if it's set to 0, pacman just print warning informing the user that he need to apply change to the daemon, i.e. restart it.

-1. Pacman is a package manager, not a system administration tool.

Dan McGee

1:37 p.m.

On Sat, May 30, 2009 at 6:54 AM, Daenyth Blank wrote:

...

On Sat, May 30, 2009 at 05:28, ludovic coues wrote:

...
Maybe that a PKGBUILD runned solution, could allow to set some pacman's config for this. Like a field " auto-restart_daemon = 1", wich you can set to 0, if you don't want. Same for adding user.

If the field is to 1, pacman manage it by itself, if it's set to 0, pacman just print warning informing the user that he need to apply change to the daemon, i.e. restart it.

-1. Pacman is a package manager, not a system administration tool.

I think I can safely speak for most of the developers when I say Arch will *never* get in the business of restarting daemons. Ever. If we do it is a bug, because the implications of it are just too great. Think about upgrading the httpd package on a relatively high-traffic site (e.g. archlinux.org). Think we want the webserver to just restart whenever it wants? Now do the same with xinetd, mysql, and you start to see huge problems. -Dan

Allan McRae

1:46 p.m.

New subject: [arch-general] Fix or not fix? install scriptlets with user handling.

Dan McGee wrote:

...

On Sat, May 30, 2009 at 6:54 AM, Daenyth Blank wrote:

...
On Sat, May 30, 2009 at 05:28, ludovic coues wrote:

...
Maybe that a PKGBUILD runned solution, could allow to set some pacman's config for this. Like a field " auto-restart_daemon = 1", wich you can set to 0, if you don't want. Same for adding user.

If the field is to 1, pacman manage it by itself, if it's set to 0, pacman just print warning informing the user that he need to apply change to the daemon, i.e. restart it.

-1. Pacman is a package manager, not a system administration tool.

I think I can safely speak for most of the developers when I say Arch will *never* get in the business of restarting daemons. Ever. If we do it is a bug, because the implications of it are just too great. Think about upgrading the httpd package on a relatively high-traffic site (e.g. archlinux.org). Think we want the webserver to just restart whenever it wants? Now do the same with xinetd, mysql, and you start to see huge problems.

BTW, this has been discussed in the bug track a couple of years ago: http://bugs.archlinux.org/task/9030 Allan

Jan de Groot

1:55 p.m.

New subject: [arch-general] Fix or not fix? install scriptlets with user handling.

On Sat, 2009-05-30 at 08:37 -0500, Dan McGee wrote:

...

I think I can safely speak for most of the developers when I say Arch will *never* get in the business of restarting daemons. Ever. If we do it is a bug, because the implications of it are just too great. Think about upgrading the httpd package on a relatively high-traffic site (e.g. archlinux.org). Think we want the webserver to just restart whenever it wants? Now do the same with xinetd, mysql, and you start to see huge problems.

To process a kernel update, your system should be rebooted too. Should we do that from post_upgrade also? :P I agree with Dan here. I don't like packages restarting or stopping crap behind my back. Since we do not have configuration file merging integrated in pacman, I also see no way to do this in a good fashion. Let's say you upgrade apache 1.3 to 2.2, after which the configuration scheme has changed completely. Just stop the old apache, install apache 2.2, install a shitload of pacnew files, start apache and it fails and won't come up again until the administrator updates all configs. Compare this to the case where apache will keep running until the next run of logrotate where it will crash then. Another thing is upgrading in chroots. Last week I've been updating a debian etch chroot install to debian lenny. I had to edit the postrm and postinst files for postfix and snmpd, because they couldn't stop and start postfix and snmpd. Apt would not let me continue without fixing this first. I ended up with two chroots that didn't allow me to umount the bind-mounted /proc, /dev and such, with no way to find out which stupid daemon was still running inside the chroot.

Allan McRae

1:57 p.m.

Jan de Groot wrote:

...

On Sat, 2009-05-30 at 08:37 -0500, Dan McGee wrote:

...
I think I can safely speak for most of the developers when I say Arch will *never* get in the business of restarting daemons. Ever. If we do it is a bug, because the implications of it are just too great. Think about upgrading the httpd package on a relatively high-traffic site (e.g. archlinux.org). Think we want the webserver to just restart whenever it wants? Now do the same with xinetd, mysql, and you start to see huge problems.

To process a kernel update, your system should be rebooted too. Should we do that from post_upgrade also? :P

I agree with Dan here. I don't like packages restarting or stopping crap behind my back. Since we do not have configuration file merging integrated in pacman, I also see no way to do this in a good fashion. Let's say you upgrade apache 1.3 to 2.2, after which the configuration scheme has changed completely. Just stop the old apache, install apache 2.2, install a shitload of pacnew files, start apache and it fails and won't come up again until the administrator updates all configs. Compare this to the case where apache will keep running until the next run of logrotate where it will crash then.

Or it could get even more confusing: http://www.ibiblio.org/harris/500milemail.html

Attila

8:02 p.m.

On Samstag, 30. Mai 2009 15:37 Dan McGee wrote:

...

I think I can safely speak for most of the developers when I say Arch will never get in the business of restarting daemons. Ever. If we do it is a bug, because the implications of it are just too great. Think about upgrading the httpd package on a relatively high-traffic site (e.g. archlinux.org). Think we want the webserver to just restart whenever it wants? Now do the same with xinetd, mysql, and you start to see huge problems.

I understand what you mean because i run a server at home and therefore i know about such possible problems. I'm only wondering that everybody think he is on the safe side that you don't restart it as a rule in every case. At example if the package is a daemon without any dependence to another one this is only defering a possible problem in the future to the next reboot, not more and for me not better. But i don't want to say that you have to change this because for a single daemon i would say that this is possible but for a combination of them as you said this is too much work for a problem who could (and should) be solved from the user. See you, Attila

5444

Age (days ago)

5447

Last active (days ago)

List overview

Download

32 comments

15 participants

participants (15)

Allan McRae
Attila
Daenyth Blank
Damjan Georgievski
Dan McGee
Frédéric Perrin
Gerardo Exequiel Pozzi
Giovanni Scafora
Grigorios Bouzakis
Jan de Groot
Jan Spakula
Johannes Held
ludovic coues
RedShift
Xavier