From: [email protected]

Sir, your style of communication is very harsh, and I'm afraid that this
will prevent you from getting help from a lot of volunteers and authors
of open software. But maybe it's just because of the english language.

On Mon, Aug 16, 2004 at 11:55:24AM +0200, Dariush Pietrzak wrote:

On Sun, Aug 15, 2004 at 02:13:41PM +0000, Gerrit Pape wrote:

On Sun, Aug 15, 2004 at 12:59:59PM +0200, Dariush Pietrzak wrote:

If you mean an init script in /etc/init.d/ for starting and stopping runit by ``normal/traditional way'', then, no, this is not supported.

That's the way I\m running it right now, and this seem like 'debian way'

Sure it works on the first glance, but it's not supported.

Are you saying it won't work in the long run? What kind of problems are
you expecting? Or are you saying - this solution is not glorious enough,
and you don't want your name or name of your creation associated with it?

It's unfortunate that you don't understand what I write, I pointed you
to the documentation that states the reasons, and I say it's not
supported. I say your solution is not a good one, you never asked for
an alternative, better solution. Hint: runit runs on system, other than Debian, that don't have /etc/inittab, it's documented.

It would break the feature of runit providing a process hierarchy with pid 1 as root to hook in service daemons, to run them in a guaranteed

To tell the truth, I don't understand what you just said.

Yes, but I'm afraid I personally cannot help you, I already pointed you
to the public mailing list, it may well be that you get help for free
from people there.

It doesen't and you just ignore any reports that say otherwise.

Funny, where you have this idea from? In retrospect ignoring this very
bug report would've saved me time, this discussion didn't help me in any
way to improve my Debian works.

I don't think it's a good idea; runsvdir definitely shouldn't be handled through an init script.

why not?

It's unfortunate that you don't understand what I write. I already told
you, and wrote it in the documentation. Sorry, I don't know what I
should write you here better to have you understand.

I don't care what you do personally, but please don't distribute a
package that does that. I suggest you try to better understand what
the benefits of the runit package are, and why it is designed the
way it is, if you want to use it. If you have any questions, feel
free to ask on the <[email protected]> mailing list, such
topics are discussed there.

OK, so what should I do now?

I don't care what you do personally, but please don't distribute a
package that does that. I suggest you try to better understand what
the benefits of the runit package are, and why it is designed the
way it is, if you want to use it. If you have any questions, feel
free to ask on the <[email protected]> mailing list, such
topics are discussed there.

I'm about to close this bug report.

Regards, Gerrit.


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

Package: runit
Version: 1.0.4-1
Severity: wishlist

I would like ability to install it without touching inittab, installation fails with
locked-down setup, and then the system is left with runit in half-configured state and
one cannot install nor purge it, like this:

Unpacking runit (from .../tmp/runit_1.0.4-1_i386.deb) ...
Setting up runit (1.0.4-1) ...
Adding SV inittab entry...
/var/lib/dpkg/info/runit.postinst: kill: (1) - No such process
dpkg: error processing runit (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
runit


and like this:
apt-get remove --purge runit
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
runit*
0 packages upgraded, 0 newly installed, 1 to remove and 14 not upgraded.
1 packages not fully installed or removed.
Need to get 0B of archives. After unpacking 442kB will be freed.
Do you want to continue? [Y/n]
(Reading database ... 68741 files and directories currently installed.) Removing runit ...
dpkg - warning: while removing runit, directory `/etc/runit/getty-5' not empty so not removed.
dpkg - warning: while removing runit, directory `/etc/runit' not empty so not removed.
Removing SV inittab entry...
/var/lib/dpkg/info/runit.postrm: kill: (1) - No such process
dpkg: error processing runit (--purge):
subprocess post-removal script returned error exit status 1
Errors were encountered while processing:
runit
E: Sub-process

It would generally be nicer if it wouldn't mess with inittab that much...

-- System Information
Debian Release: 3.0
Kernel Version: Linux forumakad 2.4.26-bsd21i #1 Mon May 31 07:56:17 CEST 2004 i686 unknown



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

On Fri, Aug 13, 2004 at 11:38:51AM +0200, Dariush Pietrzak wrote:

I would like ability to install it without touching inittab,

Please see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=234106

Other packages rely on runit adding the inittab entry and so enabling
service supervision.

installation fails with locked-down setup, and then the system is
left with runit in half-configured state and one cannot install nor
purge it, like this:

Unpacking runit (from .../tmp/runit_1.0.4-1_i386.deb) ...
Setting up runit (1.0.4-1) ...
Adding SV inittab entry...
/var/lib/dpkg/info/runit.postinst: kill: (1) - No such process
dpkg: error processing runit (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
runit

Hmm, how comes that there's no process no 1 on your system?

and like this:
apt-get remove --purge runit
Reading Package Lists... Done
Building Dependency Tree... Done

Removing SV inittab entry...
/var/lib/dpkg/info/runit.postrm: kill: (1) - No such process
dpkg: error processing runit (--purge):

Ok same problem.

It would generally be nicer if it wouldn't mess with inittab that much...

It simply adds an entry, and removes it when uninstalled. As said
above, this is mandatory. But I'm open for suggestions if you know a
better way to handle it. I still wonder how it comes that no process
with pid 1 is running on your system.

Regards, Gerrit.


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

On Fri, Aug 13, 2004 at 11:48:22AM +0000, Gerrit Pape wrote:

On Fri, Aug 13, 2004 at 11:38:51AM +0200, Dariush Pietrzak wrote:

I would like ability to install it without touching inittab,

Please see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=234106

this only streghtens the argument that it should not mess with inittab,

Other packages rely on runit adding the inittab entry and so enabling
service supervision.

I don't understand, does this mean that the only way to run runit is with inittab? What about normal/traditional way of running it as daemon?

installation fails with locked-down setup, and then the system is
left with runit in half-configured state and one cannot install nor
purge it, like this:

Unpacking runit (from .../tmp/runit_1.0.4-1_i386.deb) ...
Setting up runit (1.0.4-1) ...
Adding SV inittab entry...
/var/lib/dpkg/info/runit.postinst: kill: (1) - No such process
dpkg: error processing runit (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
runit

Hmm, how comes that there's no process no 1 on your system?

I run my servers inside vserver, so either there's no process no 1, or
there is no access to this process.

Removing SV inittab entry...
/var/lib/dpkg/info/runit.postrm: kill: (1) - No such process
dpkg: error processing runit (--purge):

Ok same problem.

well, I see that, but how am I supposed to remove runit now?

above, this is mandatory. But I'm open for suggestions if you know a

It would be nice if it wouldn't just die when kill to process 1 fails,
( and it can fail in multitude of ways, on one machine it fails with 'No
such process', on another with 'Access denied' ).
I'll try to suggest alternative solution with runit running as daemon, this already is only a 'wishlist' so maybe merging it with 234106 would make
sense..
--
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

On Sat, Aug 14, 2004 at 04:53:17PM +0200, Dariush Pietrzak wrote:

On Fri, Aug 13, 2004 at 11:48:22AM +0000, Gerrit Pape wrote:

On Fri, Aug 13, 2004 at 11:38:51AM +0200, Dariush Pietrzak wrote:

I would like ability to install it without touching inittab,

Other packages rely on runit adding the inittab entry and so enabling service supervision.

I don't understand, does this mean that the only way to run runit is with inittab? What about normal/traditional way of running it as daemon?

You can either use runit's service supervision through /etc/inittab, or
by replacing sysv init, and using runit as process no 1 (see the
runit-run package).

If you mean an init script in /etc/init.d/ for starting and stopping
runit by ``normal/traditional way'', then, no, this is not supported.
It would break the feature of runit providing a process hierarchy with
pid 1 as root to hook in service daemons, to run them in a guaranteed
process state.

http://smarden.org/runit/benefits.html#state

Removing SV inittab entry...
/var/lib/dpkg/info/runit.postrm: kill: (1) - No such process
dpkg: error processing runit (--purge):

Ok same problem.

well, I see that, but how am I supposed to remove runit now?

Edit /var/lib/dpkg/info/runit.postinst, and remove the line that says
``kill -HUP 1''. Then run
# dpkg --purge runit

above, this is mandatory. But I'm open for suggestions if you know a

It would be nice if it wouldn't just die when kill to process 1 fails,

Ok, I think I'll change it to ``kill -HUP 1 || :'' in the postinst.

I'll try to suggest alternative solution with runit running as daemon, this

I don't think this is a good idea for the reason mentioned above.

Regards, Gerrit.
--
Open projects at http://smarden.org/pape/.


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

If you mean an init script in /etc/init.d/ for starting and stopping
runit by ``normal/traditional way'', then, no, this is not supported.

That's the way I\m running it right now, and this seem like 'debian way'
to me. This way runit does not disturb other deamons and parts of the
system. I'd consider this playing nice feature as rather important.

It would break the feature of runit providing a process hierarchy with
pid 1 as root to hook in service daemons, to run them in a guaranteed

To tell the truth, I don't understand what you just said.

process state.
http://smarden.org/runit/benefits.html#state

This is anit-init.d rant, which is kind of moot considering high quality
of debian's init scripts, and the fact that I don't want to rewrite all
those scripts, I just want to plug runit into existing system.

Removing SV inittab entry...
/var/lib/dpkg/info/runit.postrm: kill: (1) - No such process
dpkg: error processing runit (--purge):

Ok same problem.

well, I see that, but how am I supposed to remove runit now?

Edit /var/lib/dpkg/info/runit.postinst, and remove the line that says
``kill -HUP 1''. Then run
# dpkg --purge runit

Classy, I did it differently, but this seems less messy

above, this is mandatory. But I'm open for suggestions if you know a

It would be nice if it wouldn't just die when kill to process 1 fails,

Ok, I think I'll change it to ``kill -HUP 1 || :'' in the postinst.

Thanks.

I'll try to suggest alternative solution with runit running as daemon, this

I don't think this is a good idea for the reason mentioned above.

Ok, so maybe would you consider providing alternative package, or maybe
you don't mind me uploading such, although this would make little sense, considering tiny amount of changes to provide this functionality.

regards,
--
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

On Sun, Aug 15, 2004 at 12:59:59PM +0200, Dariush Pietrzak wrote:

If you mean an init script in /etc/init.d/ for starting and stopping
runit by ``normal/traditional way'', then, no, this is not supported.

That's the way I\m running it right now, and this seem like 'debian way'

Sure it works on the first glance, but it's not supported.

to me. This way runit does not disturb other deamons and parts of the
system. I'd consider this playing nice feature as rather important.

The runit package as is doesn't ``disturb other deamons and parts of the system'', I don't know where you have that idea from. Having a program respawned from /etc/inittab is perfectly fine, and not against any
``debian way''. That's sysvinit.

Your system doesn't have an init process running, that's why you have a problem. Obviously you would have similar problems with getty services
for example.

It would break the feature of runit providing a process hierarchy with
pid 1 as root to hook in service daemons, to run them in a guaranteed

To tell the truth, I don't understand what you just said.

It's about the guaranteed process state outlined in the web page I
pointed to, this is part of service supervision. May I ask for the
reasons you want to use the runit package?

process state.
http://smarden.org/runit/benefits.html#state

This is anit-init.d rant, which is kind of moot considering high quality
of debian's init scripts, and the fact that I don't want to rewrite all
those scripts, I just want to plug runit into existing system.

Hey, you're talking to the author of the page, and I don't think it's a
rant, but stating facts.

There's no need to ``rewrite all those scripts'', I don't know where you
have this idea from; and the runit package as is plugs perfectly into an existing Debian system AFAICS, I see no reason to change this.

above, this is mandatory. But I'm open for suggestions if you know a

It would be nice if it wouldn't just die when kill to process 1 fails,

Ok, I think I'll change it to ``kill -HUP 1 || :'' in the postinst.

Thanks.

I meant the postrm script, not postinst, sorry.

I'll try to suggest alternative solution with runit running as daemon, this

I don't think this is a good idea for the reason mentioned above.

Ok, so maybe would you consider providing alternative package, or maybe
you don't mind me uploading such, although this would make little sense, considering tiny amount of changes to provide this functionality.

I don't think it's a good idea; runsvdir definitely shouldn't be handled through an init script. I don't care what you do personally, but please
don't distribute a package that does that. I suggest you try to better understand what the benefits of the runit package are, and why it is
designed the way it is, if you want to use it. If you have any
questions, feel free to ask on the <[email protected]>
mailing list, such topics are discussed there.

http://skarnet.org/lists/

Regards, Gerrit.
--
Open projects at http://smarden.org/pape/.


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

On Sun, Aug 15, 2004 at 02:13:41PM +0000, Gerrit Pape wrote:

On Sun, Aug 15, 2004 at 12:59:59PM +0200, Dariush Pietrzak wrote:

If you mean an init script in /etc/init.d/ for starting and stopping runit by ``normal/traditional way'', then, no, this is not supported.

That's the way I\m running it right now, and this seem like 'debian way'

Sure it works on the first glance, but it's not supported.

Are you saying it won't work in the long run? What kind of problems are
you expecting? Or are you saying - this solution is not glorious enough,
and you don't want your name or name of your creation associated with it?

The runit package as is doesn't ``disturb other deamons and parts of the system'', I don't know where you have that idea from. Having a program

Well, I had problems with setting it up.
Other people had other problems, and you pointed me to their reports.
Those problems wouldn't exist if it wouldn't try to take over the system
and just plug in like other parts of debian do.

respawned from /etc/inittab is perfectly fine, and not against any

Well, for some this is perfectly fine, for others - it isn't.
No other service tries to take over /etc/inittab, thus, I figure, this is
not 'debian way'.

Your system doesn't have an init process running, that's why you have a

I don't have a problem. Runit's packaging does. It's very aggressive and
tries to take over the system, without a good reason ( well, at least from
my point of view ).

It would break the feature of runit providing a process hierarchy with pid 1 as root to hook in service daemons, to run them in a guaranteed

To tell the truth, I don't understand what you just said.

It's about the guaranteed process state outlined in the web page I
pointed to, this is part of service supervision. May I ask for the
reasons you want to use the runit package?

I've got deamons that I would like to be kept running, those are usually faulty pieces of software, they do die ocassionally, or they generally need
to be fired at boot and kept running.
So I tried deamontools, but it seems like they're under restrictive
licence, it looks like you rewrote deamontools under GPL under the 'runit' name. So I went for it...

There's no need to ``rewrite all those scripts'', I don't know where you
have this idea from; and the runit package as is plugs perfectly into an existing Debian system AFAICS, I see no reason to change this.

I don't know where do you get this idea of it pluggin 'perfectly'.
It doesen't and you just ignore any reports that say otherwise.

I don't think it's a good idea; runsvdir definitely shouldn't be handled through an init script.

why not?

don't distribute a package that does that.

OK, so what should I do now? Can I use your code, or maybe you're planning
on changing licence?

--
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)