PATH
case $1 in
start)
echo -n Starting qmail: svscan
cd /var/qmail/supervise
env - PATH=$PATH svscan
echo $! /var/run/svscan.pid
echo .
;;
stop)
echo -n Stopping qmail: svscan
echo -n qmailn/svscan.pid
svc -dx /var/qmail/supervise/*
echo -n logging
svc -dx /var/qmail/supervise/*/log
echo .
;;
stat
Florian Heiderich [EMAIL PROTECTED] wrote:
PLUTO:/etc/rc.d # tcpserver: option requires an argument -- c
setuidgid: fatal: unable to run /usr/local/bin/multilog: access denied
You didn't do the install correctly (specifically, you failed to create
one of the necessary control files for this
./Maildir splogger qmail
(env - PATH=/var/qmail/bin:/usr/local/bin \
QMAILQUEUE=/var/qmail/bin/qmail-scanner-queue.pl \
/usr/local/bin/supervise /usr/local/bin/tcpserver -H -R -x /etc/tcp.smtp.cdb \
-c 100 -u 109 -g 103 0 smtp \
/usr/local/bin/rblsmtpd -rrelays.orbs.org
I'm running RedHat 6.2.
I seem to be having problems with daemontools, and the supervise
scripts.
I'm trying to run daemontools-0.76. I installed it by
$ cd /usr/admin/daemontools-0.76
and then
$ ./package/install
I then linked in the 2 directories,
/var/qmail/supervise/qmail-smtpd
Al Sparks [EMAIL PROTECTED] wrote:
Note the error unable to start qmail-smtpd/run: ex. Note also, that
tcpserver is not started in any of this.
When I manually run /service/qmail-smtpd/run tcpserver does start.
/service/qmail-smtpd/run, which was taken from Life with qmail, has
the
--- Charles Cazabon [EMAIL PROTECTED] wrote:
The first line of the script is wrong and is not from Life with qmail.
Then, the only ex in the script is part of exec. Are you sure you
don't have some nonprintable characters in there?
Charles
The thing of it is, I stared and stared at that
On 07 Aug 2001 12:43:23 -0700, Al Sparks wrote:
When I manually run /service/qmail-smtpd/run tcpserver does start.
/service/qmail-smtpd/run, which was taken from Life with qmail, has
the following in it:
**
ILDUID=`id -u qmaild`
Right here is your problem.. If you notice ILDUID is not a
Hi!!!
I've been running my Qmail server for 7 months now, without any problems what so ever!!
But yesterday it stopped sending any outgouing mail. Incoming still works fine
I tried a restart which did not help at all.
When qmail starts i get the following error message:
supervise
which did not help at all.
When qmail starts i get the following error message:
supervise: fatal: unable to acquire
qmail-send/supervise/lock: temporary failure
supervise: fatal: unable to acquire qmail-smtpd/supervise/lock:
temporary failure
What has happened???
Looks to me like you're
--
when i look at my processes i get two lines like this:
#ps -aux
root 12102 0.0 0.0 00 ?Z02:14 0:00
[supervise defunct]
Has anyone seen this before, and is it a problem?
Regards,
David Dahl
yes, it is
check your logs, probably a process controlled by supervise isn't running
properly.. Iv'e got the problem, that supervise write's it's error
messages only to tty1. try to run svscan from commandline without
backgrounding it, and check the output
At 14:35 15.07.2001 -0500, David
: tcp0 0
*:smtp *:* LISTEN
5711/tcpserver
i'm not sure what all of this means...
yes, it is
check your logs, probably a process controlled by supervise isn't
running properly.. Iv'e got the problem, that supervise write's
it's error
I think i know what is wrong...
here is the output of svstat /service/*:
(i ran this as an unpriveleged user)
=
svstat /service/*
/service/log: unable to open supervise/ok: access denied
/service/qmail-pop3d: unable to open supervise/ok: access denied
/service/qmail-send
I just restructured my supervise directory to the new method outlined in
LWQ and LWDJBDNS. After restarting the svscan process, I noticed that
the load on the machine has increased dramatically. Top shows supervise
running pretty hot:
last pid: 85737; load averages: 4.44, 2.95, 1.98
Godamnit. I hate replying to myself. I had checked the logs... but only
briefly I guess, or the process was happy for a bit? I dunno. But when I
looked at them again later (AFTER sending pointless mail to the list of
course), qmail-send's log was going nuts. Turns out I failed to properly
kill
On Wed, Jun 20, 2001 at 09:13:19AM +0900, YOON, Joo-Yung wrote:
Hi,
I just installed qmail, daemontools, ucspi-tcp.
Many strange things were cleared with help of qmail lists.
Now ps shows following things.
[snip]
$ ps ax |grep supervise
315 ?S 0:00 supervise qmail-send
Hi,
I just installed qmail, daemontools, ucspi-tcp.
Many strange things were cleared with help of qmail lists.
Now ps shows following things.
$ ps ax |grep svscan
299 ?S 0:00 svscan
4558 ttyp0S 0:00 grep svscan
$ ps ax |grep qmail
315 ?S 0:00 supervise
Bernhard Graf [EMAIL PROTECTED] wrote:
Gerrit Pape wrote
svscan should be started at boot time and never stopped until
shutdown. That ensures your services are always running with the
same (known and wanted) environment and limits.
But I don't want to bypass run levels.
Would you approve
Dave Sill [EMAIL PROTECTED] wrote:
Would you approve creating a 'down' file in the service directories and
running 'svc -u / svc -d' in init.d scripts on each service?
That's a nice idea, but it doesn't work. svscan started via inittab
isn't started until *after* the init.d scripts are
Charles Cazabon [EMAIL PROTECTED] wrote:
I could be mistaken, but I believe this behaviour depends on the order of the
various lines in inittab -- if you put svscan before the stuff called in the
standard runlevels, it should work.
Hmm, that could be it. If so, it's unfortunate that DJB's
On Mon, 18 Jun 2001, Charles Cazabon wrote:
I could be mistaken, but I believe this behaviour depends on the order
of the various lines in inittab -- if you put svscan before the stuff
called in the standard runlevels, it should work.
SysVinit, which I believe is quite common on Linux
On Sat, Jun 16, 2001 at 11:28:35PM +0900, YOON, Joo-Yung wrote:
Thanks for your help.
I checked the system, and found out that there were 2 places that initiate
svscan. The one is /etc/inittab, and the other is /etc/init.d/svscan.
Life with Qmail (installation document) misses the point
Gerrit Pape wrote
Better remove /etc/init.d/svscan and corresponding links and use the
inittab entry as recommended by the software author.
Why?
--
Bernhard Graf [EMAIL PROTECTED]
On Sun, Jun 17, 2001 at 03:18:37PM +0200, Bernhard Graf wrote:
Gerrit Pape wrote
Better remove /etc/init.d/svscan and corresponding links and use the
inittab entry as recommended by the software author.
Why?
svscan should be started at boot time and never stopped until shutdown.
That
Gerrit Pape wrote
On Sun, Jun 17, 2001 at 03:18:37PM +0200, Bernhard Graf wrote:
Gerrit Pape wrote
Better remove /etc/init.d/svscan and corresponding links and use the
inittab entry as recommended by the software author.
Why?
svscan should be started at boot time and never
On Sun, Jun 17, 2001 at 05:18:29PM +0200, Bernhard Graf wrote:
Gerrit Pape wrote
svscan should be started at boot time and never stopped until shutdown.
That ensures your services are always running with the same (known and wanted)
environment and limits.
But I don't want to bypass run
.
It is supervise:fatal:unable to start supervise/run:file does not exist.
The directories related are as follows.
1. /service
# ls -l /service
lrwxrwxrwx1 root root 31 6¿ù 16 18:05 qmail-send -
/var/qmail/supervise/qmail-send
lrwxrwxrwx1 root root 32 6¿ù 16 18:05 qmail
YOON, Joo-Yung [EMAIL PROTECTED] writes:
drwx--3 root root 4096 6¿ù 16 23:16 supervise
(There is another supervise inside the supervise directory.)
This is left from your previous wrong setup. There are supervise
directories on overy first level directory now. To remove
Dear Frank,
Thanks for your help.
I deleted all supervise directories, and it seems to work.
Warm regards,
On Sat, Jun 16, 2001 at 04:49:20PM +0200, Frank Tegtmeyer wrote:
YOON, Joo-Yung [EMAIL PROTECTED] writes:
drwx--3 root root 4096 6¿ù 16 23:16 supervise
Stephen Bosch [EMAIL PROTECTED] wrote:
So, is Charles right?
He knows a thing or two about qmail...
Does this indicate somebody is reattempting delivery?
Looks like it to me.
No supervise directory... Further evidence that supervise isn't
running.
*rattles head*
So... okay... where
Stephen Bosch [EMAIL PROTECTED] wrote:
Dave Sill wrote:
Logging via splogger (syslog).
Which is deprecated in LWQ, now, correct?
Yes.
Sure that's qmail-smtpd/log/run? Looks more like qmail-smtpd/run.
D'oh!
#!/bin/sh
exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t
Dave Sill wrote:
Stephen Bosch [EMAIL PROTECTED] wrote:
Dave Sill wrote:
Logging via splogger (syslog).
Which is deprecated in LWQ, now, correct?
Yes.
Sure that's qmail-smtpd/log/run? Looks more like qmail-smtpd/run.
D'oh!
#!/bin/sh
exec /usr/local/bin/setuidgid qmaill
Stephen Bosch [EMAIL PROTECTED] wrote:
Well, my logs are filling up with garbage
Garbage or log entries? Sample, please?
(and I get that silly file
does not exist error when I run qmail stat)
Sample?
-Dave
other qmail installations don't do that.
The queue is empty.
Then, there's this:
[root@hotcube qmail]# /etc/rc.d/init.d/qmail stat
qmail-send: up (pid 27564)
qmail-smtpd: up (pid 27566)
qmail-send/log: unable to open supervise/ok: file does not exist
qmail-smtpd/log: unable to open
)
qmail-smtpd: up (pid 27566)
qmail-send/log: unable to open supervise/ok: file does not exist
qmail-smtpd/log: unable to open supervise/ok: file does not exist
That means supervise isn't running for the log services.
Okay. So I checked for sticky bits on the appropriate directories:
[root
Stephen Bosch [EMAIL PROTECTED] wrote:
Dave Sill wrote:
Stephen Bosch [EMAIL PROTECTED] wrote:
Well, my logs are filling up with garbage
Garbage or log entries? Sample, please?
Sorry -- it's just that I quoted it at great length before...
[...]
Jun 12 14:09:12 hotcube qmail:
Charles Cazabon wrote:
Stephen Bosch [EMAIL PROTECTED] wrote:
Dave Sill wrote:
Stephen Bosch [EMAIL PROTECTED] wrote:
Well, my logs are filling up with garbage
Garbage or log entries? Sample, please?
Sorry -- it's just that I quoted it at great length before...
[...]
-send/log
service when you're logging via splogger/syslog.
[root@hotcube qmail]# /etc/rc.d/init.d/qmail stat
qmail-send: up (pid 27564)
qmail-smtpd: up (pid 27566)
qmail-send/log: unable to open supervise/ok: file does not exist
qmail-smtpd/log: unable to open supervise/ok: file does
Stephen Bosch [EMAIL PROTECTED] wrote:
Each of those messages has a different qmail-queue PID. From this, you
can deduce that the sender is connecting to your server, sending the
message, and somehow disconnecting or misinterpreting qmail's response to
the DATA command. The sender
Stephen Bosch [EMAIL PROTECTED] writes:
qmail-send/log: unable to open supervise/ok: file does not exist
There is no need for qmail-send/log. qmail-send starts up the logger
by itself as given on it's command line. See /var/qmail/rc.
Seems that you simply messed up the logging. What do you
Frank Tegtmeyer [EMAIL PROTECTED] wrote:
Stephen Bosch [EMAIL PROTECTED] writes:
qmail-send/log: unable to open supervise/ok: file does not exist
There is no need for qmail-send/log.
Sure there is, if you want the logging supervised.
qmail-send starts up the logger
by itself as given
Frank Tegtmeyer wrote:
Stephen Bosch [EMAIL PROTECTED] writes:
qmail-send/log: unable to open supervise/ok: file does not exist
There is no need for qmail-send/log. qmail-send starts up the logger
by itself as given on it's command line. See /var/qmail/rc.
Seems that you simply
Dave Sill wrote:
Frank Tegtmeyer [EMAIL PROTECTED] wrote:
Stephen Bosch [EMAIL PROTECTED] writes:
qmail-send/log: unable to open supervise/ok: file does not exist
There is no need for qmail-send/log.
Sure there is, if you want the logging supervised.
qmail-send starts up
site. That way, once I leave them, they can ask questions on the
mailing list, and everybody will know where their files are.
I don't have the overview here -- this supervise logging stuff is
really opaque for me.
svscan looks in /service for directories with a run file.
svscan starts up
Stephen Bosch [EMAIL PROTECTED] wrote:
Okay, here is what I have in /var/qmail/rc:
#!/bin/sh
# Using splogger to send the log through syslog.
# Using procmail to deliver messages to /var/spool/mail/$USER by
default.
exec env - PATH=/var/qmail/bin:$PATH \
qmail-start '|preline procmail'
Dave Sill wrote:
Stephen Bosch [EMAIL PROTECTED] wrote:
Okay, here is what I have in /var/qmail/rc:
#!/bin/sh
# Using splogger to send the log through syslog.
# Using procmail to deliver messages to /var/spool/mail/$USER by
default.
exec env - PATH=/var/qmail/bin:$PATH \
on). Is this normal? My other qmail installations don't do that.
The queue is empty.
Then, there's this:
[root@hotcube qmail]# /etc/rc.d/init.d/qmail stat
qmail-send: up (pid 27564)
qmail-smtpd: up (pid 27566)
qmail-send/log: unable to open supervise/ok: file does not exist
qmail-smtpd/log: unable
+ supervise-scripts-3.3.
I'm monitoring the behaviour of tcpserver for the pop service ( simple 'ps -
aux | grep tcpserver | grep pop' and I get, obviously, just one is
running ). Sometimes, supervise tries to restart tcpserver and I see 2
tcpservers. Then the second dies ( port is already bind
Renato [EMAIL PROTECTED] wrote:
I'm monitoring the behaviour of tcpserver for the pop service ( simple 'ps -
aux | grep tcpserver | grep pop' and I get, obviously, just one is
running ). Sometimes, supervise tries to restart tcpserver and I see 2
tcpservers. Then the second dies ( port
Hi Charles,
Thanks for your answer.
Renato [EMAIL PROTECTED] wrote:
I'm monitoring the behaviour of tcpserver for the pop service (
simple 'ps -
aux | grep tcpserver | grep pop' and I get, obviously, just one is
running ). Sometimes, supervise tries to restart tcpserver and I see 2
Renato [EMAIL PROTECTED] wrote:
No. tcpserver shouldn't randomly die.
Is there a way to tune up supervise ? (time-out, any other parameters ?)
Perhaps you're running it with memory or other process limits, or its
hitting a system-wide limit? Without specific information
Hi All,
For which way could I know if daemontools is installed
already?
What supervise qmail-send, supervise qmail-smtpd and
supervise qmail-pop3d are used for?
Thanks,
Pablo
___
Do You Yahoo!?
Yahoo! Messenger: Comunicación
Pablo Buenaventura [EMAIL PROTECTED] wrote:
For which way could I know if daemontools is installed
already?
If you've got /usr/local/bin/supervise, you've probably got
daemontools. On Red Hat, you could check for an RPM:
rpm -qa | grep daemontools
What supervise qmail-send, supervise qmail
Buenaventura([EMAIL PROTECTED])@2001.05.08 11:42:55 +:
Hi All,
For which way could I know if daemontools is installed
already?
What supervise qmail-send, supervise qmail-smtpd and
supervise qmail-pop3d are used for?
Thanks,
Pablo
The high CPU usage problem went away after I fixed the properties of the
/var/qmail/supervise/qmail-pop3d and qmail-pop3d/log directories. I hadn't
followed LWQ when I first created them.
Now everything seems to be fine. And I've learned a lot about qmail in the
last few days. :-)
Time
Carl Jeptha wrote:
- Original Message -
From: "Carl Jeptha" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 12, 2001 7:25 PM
Subject: superscripts error
Hi,
Thanks for your help. But I cannot rebuild the supervise scripts. It ends
with an error - c
Hi, folks.
Thanks to the mailing list archives, I've been able to configure qmail-pop3d
to run under supervise...almost. I have one remaining problem: I still get
"Connection refused" when I telnet to port 110.
These are the processes running on the system:
$ ps -ax | grep q
On Sat, Apr 14, 2001 at 01:38:03PM -0400, Rehan Zaidi wrote:
Hi, folks.
Thanks to the mailing list archives, I've been able to configure qmail-pop3d
to run under supervise...almost. I have one remaining problem: I still get
"Connection refused" when I telnet t
From: "Rehan Zaidi" [EMAIL PROTECTED]
This is the same thing as I have in the /var/qmail/supervise/qmail-pop3d/run
script...
What if you run the /var/qmail/supervise/qmail-pop3d/run script from the
command line? Maybe there is a syntax error in there? Is there anything in
the lo
Thanks to Mark and David for the quick replies. The problem was that the
scripts weren't executable. I assumed that they didn't need to be because
SMTP and send seemed to be working fine, and the permissions for those run
scripts didn't include execution.
Next question... Supervise is using 95
didn't include execution.
Then they didn't run. Most likely what /is/ running is a script you
started manually. See my thoughts on your next question.
Next question... Supervise is using 95+% of the CPU on the system (RedHat
7.0) when qmail is running and 80-90% when it's not. Is that normal
- Original Message -
From: "Rehan Zaidi" [EMAIL PROTECTED]
to run under supervise...almost.
/usr/bin/tcpserver -v -R 0 pop-3 /var/qmail/bin/qmail-popup myhost \
/usr/local/bin/checkvpw /var/qmail/bin/qmail-pop3d Maildir
I had a hell of a time also - mainly because I did N
On Mon, Mar 19, 2001 at 10:22:20AM -0500, Peter Cavender wrote:
I want to run the openssh daemon under supervise...should my "run" script be:
#!/bin/sh
exec /usr/local/sbin/sshd -D
I am not sure what options to use with sshd.
As above it seems to work;
if I use no options it
On Wed, Mar 28, 2001 at 12:20:50AM -0800, David Benfell wrote:
On Mon, Mar 19, 2001 at 10:22:20AM -0500, Peter Cavender wrote:
I want to run the openssh daemon under supervise...should my "run" script be:
#!/bin/sh
exec /usr/local/sbin/sshd -D
#!/bin/sh
exec fghack /usr/
Further to my various troubles with Qmail on RH 6.2, I have now managed to
get the SMTP server running with supervise, the problem I have been left
with is as follows!!!
The logging for Qmail is set to use multilog for both qmail-smtp and the
qmail-send programs. Only trouble
On Wed, Mar 21, 2001 at 03:22:32PM -, Iain Morrison wrote:
The logging for Qmail is set to use multilog for both qmail-smtp and the
qmail-send programs. Only trouble is that supervise is not able to start
them for some reason so all logging goes to the console.
[snip...]
Any ideas
I want to run the openssh daemon under supervise...should my "run" script be:
#!/bin/sh
exec /usr/local/sbin/sshd -D
I am not sure what options to use with sshd.
As above it seems to work;
if I use no options it flips out;
using fghack it seems to work but I always get a zombied (init
On Mon, Mar 19, 2001 at 10:22:20AM -0500, Peter Cavender wrote:
I want to run the openssh daemon under supervise...should my "run" script be:
#!/bin/sh
exec /usr/local/sbin/sshd -D
I am not sure what options to use with sshd.
As above it seems to work;
if I use no options it
Gerrit Pape wrote:
I have svscan /service started from inittab. I have the links for the
services in /service and normally do not remove them. Services are started
at boot time, no need for init scripts. If I want a service to be down
temporary, I use svc -d /service/service. Thats what I
hi
I am doing another qmail install and this time I have a /supervise directory
for dnscache, so I thought it would make sense to run qmail from there, I am
following lwq (most of the time). So I was wondering if anyone had already
adapted the lwq start up script to do this, and is it a case
I am using supervise to run qmail-ldap with OpenLDAP, pop3 and
courier-imap. I am using /var/qmail/supervise as my base, but it
could be any other place.. /supervise for instance
regards,
Lucio Jankok
: -Original Message-
: From: Neil Grant [mailto:[EMAIL PROTECTED]]
: Sent: Monday
"Neil Grant" [EMAIL PROTECTED] wrote:
I am doing another qmail install and this time I have a /supervise directory
for dnscache, so I thought it would make sense to run qmail from there, I am
following lwq (most of the time). So I was wondering if anyone had already
adapted the lw
On Mon, Mar 05, 2001 at 09:07:19AM -0500, Dave Sill wrote:
Assuming you're running svscan on /service (not /supervise) already,
e.g. from inittab, you could change the "start" section in the script
to:
echo -n "Starting qmail"
ln -s /var/qmail/supervise/
"Gerrit Pape" [EMAIL PROTECTED] wrote:
On Mon, Mar 05, 2001 at 09:07:19AM -0500, Dave Sill wrote:
Assuming you're running svscan on /service (not /supervise) already,
e.g. from inittab, you could change the "start" section in the script
to:
echo -n "Starti
On Mon, Mar 05, 2001 at 09:58:32AM -0500, Dave Sill wrote:
"Gerrit Pape" [EMAIL PROTECTED] wrote:
No, I just forgot to remove the "x" flags. Make it:
echo -n "Stopping qmail: qmail-send qmail-smtpd"
svc -d /service/qmail-send /service/qmail-smtpd
echo -n " logging"
svc
Gerrit Pape wrote:
if You really want to use such silly initscripts, better use svc
directly.
Dave Sill asked:
What makes this a "silly initscript"? What's the right way to do this
stuff in your OS religion?
Gerrit Pape replied:
I have svscan /service started from inittab... If I
thanks Dave,
I was on the right lines, I just didnt know any thing about svc.
once the links are created to /service it will start automatically on boot
up,
but if it had been stopped before shutdown (svc -d) - it will need to be
'svc -u' ed on bootup? so qmail(in init.d) should still be linked
Neil Grant writes:
once the links are created to /service it will start automatically
on boot up, but if it had been stopped before shutdown (svc -d) -
it will need to be 'svc -u' ed on bootup?
That is a question? Svc saves no history and sets no state that
survives rebooting.
so
is svscan. For example, here's my /service directory on my server:
axfrdns dnscache ftpd msql2dqmail rsyncdsshd
bray etrn httpd pop3d qmtpd smtpd tinydns
Most of these are obvious. "bray" is not a service name but instead
the name of a
Hi,
I have just followed the instructions in "Life with
qmail" and got stuck in the following :
2.8.5. Start qmail
Finally, you can start qmail:/usr/local/sbin/qmail startAnd guess what!! it gave me the following errors:supervise: fatal: unable to acquire log/supervise/lock:
Hi,
I have just followed the instructions in "Life with
qmail" and got stuck in the following :
2.8.5. Start qmail
Finally, you can start qmail:/usr/local/sbin/qmail startAnd guess what!! it gave me the following errors:supervise: fatal: unable to acquire log/supervise/lock:
Have installed qmail under
http://howto.globelinks.com/qmail-howto-freebsd.html
but getting
supervise: fatal: unable to acquire
log/supervise/lock: temporary failure
supervise: fatal: unable to acquire
qmail-send/supervise/lock: temporary failure
supervise: fatal: unable to acquire
log
Uwe Ohse writes:
On Wed, Feb 07, 2001 at 11:57:34AM -0500, Peter Brezny wrote:
I'd like to run supervise, but i would prefer the logging still take place
in /var/log/maillog.
you are mistaken.
Nonsense. Of course he prefers that the logging still take place in
/var/log/maillog
I'd like to run supervise, but i would prefer the logging still take place
in /var/log/maillog.
I've read over the examples on lifewithqmail.org and
http://matt.simerson.net/computing/qmail.toaster.shtml, but each use
multilog.
If anyone has a startup script, for qmail they would like to share
On Wed, Feb 07, 2001 at 11:57:34AM -0500, Peter Brezny wrote:
I'd like to run supervise, but i would prefer the logging still take place
in /var/log/maillog.
you are mistaken.
For example, could i just leave my /var/qmail/rc file as is and omit the
portions regarding multilog
Greg White wrote:
On Tue, Feb 06, 2001 at 05:16:36PM -0500, Peter Brezny wrote:
our new qmail install is started simply by
exec env - PATH="/var/qmail/bin:$PATH" \
qmail-start ./Maildir splogger qmail
however I've noticed a lot of people using daemontools and supervise
On Wed, 7 Feb 2001, Rahsheen Porter wrote:
I'm pretty positive the latest ver of OpenSSH does this. There was
something
on the list recently about it. I think I'm using a patch provided during
that thread though. (OpenSSH_2.3.0p1)
This off-topic here but you can get a patch here:
Hi all...
My apologies for the repeated posting to the list regarding this problem.
I did receive one reply but the suggestion was looked at and wasn't the
problem.
Is anyone aware why supervise would be giving me these errors
On Tue, Feb 06, 2001 at 05:16:36PM -0500, Peter Brezny wrote:
our new qmail install is started simply by
exec env - PATH="/var/qmail/bin:$PATH" \
qmail-start ./Maildir splogger qmail
however I've noticed a lot of people using daemontools and supervise.
What are the primary
"Peter Brezny" [EMAIL PROTECTED] writes:
What are the primary advantages of using supervise?
Among those already mentioned: reliability. You *can't* reliably
manage a service without cooperation from the parent process or the
process itself. Putting the management fun
could it be
something to do with my /var/qmail/supervise directories- who should own
these and what should the permissions be?
thanks
Neil
y /var/log/qmail directory is owned by qmaill,
That's not sufficient. What is the output from:
ls -ld / /var /var/log /var/log/qmail /var/log/qmail/smtpd
so could it be
something to do with my /var/qmail/supervise directories- who should own
these and what should the permissions be?
Look at
: supervise/lock error !!
Help !!
Anyone know why I might be getting this error ?
supervise: fatal: unable to acquire qmail-smtpd/supervise/lock: temporary
failure
supervise: fatal: unable to acquire log/supervise/lock: temporary failure
?
Dennis
Dennis [EMAIL PROTECTED] wrote:
Just wondering if anyone had any suggestions for my below problem?
Haven't heard anything from anyone yet :(
Don't send the same question to the list twice. If you're not patient, you
can go to www.qmail.org and look under "paid support".
And besides, I did
Help !!
Anyone know why I might be getting this error ?
supervise: fatal: unable to acquire qmail-smtpd/supervise/lock: temporary
failure
supervise: fatal: unable to acquire log/supervise/lock: temporary failure
?
Dennis
Dennis [EMAIL PROTECTED] wrote:
Anyone know why I might be getting this error ?
supervise: fatal: unable to acquire qmail-smtpd/supervise/lock: temporary
failure
supervise: fatal: unable to acquire log/supervise/lock: temporary failure
This normally means you've already got another
Hi all...
I keep getting this error when trying to start my new qmail installation.
supervise: fatal: unable to acquire log/supervise/lock: temporary failure
supervise: fatal: unable to acquire qmail-smtpd/supervise/lock: temporary
failure
Anyone have any suggestions as to what the problem
On Wed, Jan 31, 2001 at 10:11:36AM +1100, dennis wrote:
Hi all...
I keep getting this error when trying to start my new qmail installation.
supervise: fatal: unable to acquire log/supervise/lock: temporary failure
supervise: fatal: unable to acquire qmail-smtpd/supervise/lock: temporary
Hi together
I've got a PIII 1400 Mhz Server with 384 Mb SDRAM, the qmail is installed with
supervise-mode. Now the problem is, the supervise need the whole time 4% of the
processor-capacity. Can you explain me, is that normal??
THX for your inspirations.
Greets
Thür
, and my init scripts set up, but when I run
"qmail start", I get the following:
Starting qmail: svscan
.
supervise: fatal: unable to acquire qmail-send/supervise/lock: temporary
failure
supervise: fatal: unable to acquire log/supervise/lock: temporary
failure
supervise: fatal: unable
1 - 100 of 242 matches
Mail list logo
