On 28.11.2012 00:22, Adrian Fita wrote:
> As soon as I reinstalled policyrcd-script-zg2, invoke-rc.d is starting
> the services again.
>
> So, is this expected behaviour, or is it a bug that I should report?
I've never used policyrcd-script-zg2 and have no idea what this package
is supposed to do
On 28/11/12 01:06, Michael Biebl wrote:
> On 27.11.2012 23:59, Adrian Fita wrote:
>> On 28/11/12 00:52, Michael Biebl wrote:
>>> what does `runlevel` say?
>>
>> root@zero:~# runlevel
>> N 2
>
> Interesting. As already shown, I can't reproduce your problem.
>
> Not sure if this is because you ship
On 27.11.2012 23:59, Adrian Fita wrote:
> On 28/11/12 00:52, Michael Biebl wrote:
>> what does `runlevel` say?
>
> root@zero:~# runlevel
> N 2
Interesting. As already shown, I can't reproduce your problem.
Not sure if this is because you ship a policy-rc.d script.
It might help, moving that file
On 28/11/12 00:52, Michael Biebl wrote:
> what does `runlevel` say?
root@zero:~# runlevel
N 2
And the installed sysv-rc package info:
root@zero:~# dpkg -s sysv-rc
Package: sysv-rc
Status: install ok installed
Priority: required
Section: admin
Installed-Size: 218
Maintainer: Debian sysvinit maint
what does `runlevel` say?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
On 28/11/12 00:16, Michael Biebl wrote:
> On 27.11.2012 22:47, Adrian Fita wrote:
>> - my current runlevel is 2, I made sure that cups is indeed disabled:
>> /etc/rc2.d/K02cups
>
> What does ls -la /etc/rc?.d/???cups say?
root@zero:~# ls -la /etc/rc?.d/???cups
lrwxrwxrwx 1 root root 14 Nov 9 01:
On 27.11.2012 22:47, Adrian Fita wrote:
> - my current runlevel is 2, I made sure that cups is indeed disabled:
> /etc/rc2.d/K02cups
What does ls -la /etc/rc?.d/???cups say?
If you properly disable cups via update-rc.d, the service is not run via
invoke-rc.d. I've just tested this on my system.
On 27/11/12 23:47, Adrian Fita wrote:
> On 27/11/12 23:19, Michael Biebl wrote:
>> On 27.11.2012 20:52, Adrian Fita wrote:
>>
>>> I just did a cups package update (yes, I'm running Debian unstable) and
>>> noticed that the cups daemon was started after the upgrade. And indeed,
>>> looking in /var/l
One option would be to install and use systemd. Afaik with systemd,
one can use socket-based activation: that is, systemd listens on the
socket that your daemons will use and only starts those daemons if
something connects. You may need to manually configure that behaviour,
I don't know wh
On 27/11/12 23:19, Michael Biebl wrote:
> On 27.11.2012 20:52, Adrian Fita wrote:
>
>> I just did a cups package update (yes, I'm running Debian unstable) and
>> noticed that the cups daemon was started after the upgrade. And indeed,
>> looking in /var/lib/dpkg/info/cups.postinst, the daemon is st
On 27.11.2012 20:52, Adrian Fita wrote:
> I just did a cups package update (yes, I'm running Debian unstable) and
> noticed that the cups daemon was started after the upgrade. And indeed,
> looking in /var/lib/dpkg/info/cups.postinst, the daemon is started with
> "invoke-rc.d cups start" after eve
On 09/11/12 03:04, Tom H wrote:
> On Thu, Nov 8, 2012 at 5:59 PM, Adrian Fita wrote:
>> On 09/11/12 00:32, Tom H wrote:
>>> On Thu, Nov 8, 2012 at 5:18 PM, Adrian Fita wrote:
>>>>
>>>> So the thing is this: I have some daemons that I keep them install
On Thu, Nov 8, 2012 at 5:59 PM, Adrian Fita wrote:
> On 09/11/12 00:32, Tom H wrote:
>> On Thu, Nov 8, 2012 at 5:18 PM, Adrian Fita wrote:
>>>
>>> So the thing is this: I have some daemons that I keep them installed,
>>> but I don't start them at boo
On 09/11/12 00:32, Tom H wrote:
> On Thu, Nov 8, 2012 at 5:18 PM, Adrian Fita wrote:
>>
>> So the thing is this: I have some daemons that I keep them installed,
>> but I don't start them at boot; I like to conserve my memory resources
>> and only start the daemons
On Thu, Nov 8, 2012 at 5:18 PM, Adrian Fita wrote:
>
> So the thing is this: I have some daemons that I keep them installed,
> but I don't start them at boot; I like to conserve my memory resources
> and only start the daemons when I really need them. I have disabled them
>
So the thing is this: I have some daemons that I keep them installed,
but I don't start them at boot; I like to conserve my memory resources
and only start the daemons when I really need them. I have disabled them
with "update-rc.d -f remove", but every time I update their package,
ously been a
requirement for having /proc or other extras mounted. If things are
moved to require it then I think that is a very bad direction of
movement. It makes things that would otherwise be very simple much
more complicated. That is bad.
Note that I did specify a policy-rc.d script to disallo
On Wed, Aug 15, 2012 at 06:54:56PM -0600, Bob Proulx wrote:
> There are two issues. And I know that the /run transition was
> discussed at length in debian-devel. Unfortunately I wasn't following
> it then and only run into this problem now. I think using bind mounts
> in either of the two cases
Roger Leigh wrote:
> Bob Proulx wrote:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665827
>
> Note that this is a bug against initscripts, not debianutils.
Yes. But both are buggy! I also filed a bug against ischroot.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685034
> Is t
On Wed, Aug 15, 2012 at 05:58:03PM -0600, Bob Proulx wrote:
> Roger Leigh wrote:
> > Bob Proulx wrote:
> > > I haven't submitted a bug yet but I always have problems with sysvinit
> > > postinst depending upon ischroot and ischroot getting it wrong and
> > > that leaving a broken /run - /var/run be
Roger Leigh wrote:
> Bob Proulx wrote:
> > I haven't submitted a bug yet but I always have problems with sysvinit
> > postinst depending upon ischroot and ischroot getting it wrong and
> > that leaving a broken /run - /var/run behind. You might hit that too.
>
> If this is still happening, please
On Mon, 2012-07-23 at 19:15 +0100, Roger Leigh wrote:
> On Mon, Jul 23, 2012 at 06:27:22PM +0200, Ramon Hofer wrote:
> > I now changed the stop function to (added the if test) to get rid of
> > error messages when running `sid-sabnzbdplus stop` twice:
> > stop_sab() {
> > if [ -f /var/lib/sch
On Mon, Jul 23, 2012 at 06:27:22PM +0200, Ramon Hofer wrote:
> I now changed the stop function to (added the if test) to get rid of
> error messages when running `sid-sabnzbdplus stop` twice:
> stop_sab() {
> if [ -f /var/lib/schroot/session/sid-sab ]; then
> schroot -rq -c $NAME /etc/i
On Mon, 2012-07-23 at 10:25 +0100, Roger Leigh wrote:
> On Sun, Jul 22, 2012 at 05:27:14PM +0200, Ramon Hofer wrote:
> > On Son, 2012-07-22 at 15:58 +0100, Roger Leigh wrote:
> > > On Sun, Jul 22, 2012 at 03:25:49PM +0200, Ramon Hofer wrote:
> > > > On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wr
r seen this. It's almost certainly due to the specific
> filesystems or setup you have. Check if it's really set setuid root.
I use ext4 for the /srv filesystem. And when I run ls -l for the schroot
directories (like `ls -l /srv/chroot/sid` or inside the schroot `ls
-l /`) the UID are
d with
> 'nosuid' [1]. But this isn't the case. Here's my fstab for this schroot:
I've never seen this. It's almost certainly due to the specific
filesystems or setup you have. Check if it's really set setuid root.
> I read that chroot doesn't
On Sun, Jul 22, 2012 at 05:27:14PM +0200, Ramon Hofer wrote:
> On Son, 2012-07-22 at 15:58 +0100, Roger Leigh wrote:
> > On Sun, Jul 22, 2012 at 03:25:49PM +0200, Ramon Hofer wrote:
> > > On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> > > > I would also check the return status of schroot.
i, 20 Jul 2012 10:42:58 +0100, Roger Leigh wrote:
> > >>
> > >> > On Thu, Jul 19, 2012 at 12:34:26PM +, Ramon Hofer wrote:
> > >> >> I have some questions about starting daemons in a chroot environment
> > >> >> or rather about
On Son, 2012-07-22 at 15:58 +0100, Roger Leigh wrote:
> On Sun, Jul 22, 2012 at 03:25:49PM +0200, Ramon Hofer wrote:
> > On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> > >
> > > Firstly, add schroot to Required-(Start|Stop), since you do
> > > need it to be set up prior to starting new se
On Sun, Jul 22, 2012 at 03:25:49PM +0200, Ramon Hofer wrote:
> On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> >
> > Firstly, add schroot to Required-(Start|Stop), since you do
> > need it to be set up prior to starting new sessions.
>
> Thanks for the hint!
> I added $schroot at the end
On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> On Sat, Jul 21, 2012 at 04:52:24PM +, Ramon Hofer wrote:
> > On Sat, 21 Jul 2012 11:54:58 +, Ramon Hofer wrote:
> >
> > > I found what I did wrong: In the init.d script I used chroot instead of
> > > schroot:
> > > http://pastebin.com
t; > On Thu, Jul 19, 2012 at 12:34:26PM +, Ramon Hofer wrote:
> >> >> I have some questions about starting daemons in a chroot environment
> >> >> or rather about starting schroot on bootup.
> >> >> The reason I want to do this is to clean up my ser
On Sat, Jul 21, 2012 at 04:52:24PM +, Ramon Hofer wrote:
> On Sat, 21 Jul 2012 11:54:58 +, Ramon Hofer wrote:
>
> > I found what I did wrong: In the init.d script I used chroot instead of
> > schroot:
> > http://pastebin.com/raw.php?i=Lamy4K4a
> >
> > Could you please help me with the cor
On Sat, 21 Jul 2012 11:54:58 +, Ramon Hofer wrote:
> I found what I did wrong: In the init.d script I used chroot instead of
> schroot:
> http://pastebin.com/raw.php?i=Lamy4K4a
>
> Could you please help me with the correct command?
> Instead of `chroot /srv/chroot/sid /etc/init.d/sabnzbdplus
On Fri, 20 Jul 2012 17:32:14 +0100, Roger Leigh wrote:
> On Fri, Jul 20, 2012 at 12:48:49PM +, Ramon Hofer wrote:
>> On Fri, 20 Jul 2012 10:42:58 +0100, Roger Leigh wrote:
>>
>> > On Thu, Jul 19, 2012 at 12:34:26PM +, Ramon Hofer wrote:
>> >> I have s
On Fri, 20 Jul 2012 14:24:11 -0600, Bob Proulx wrote:
> First I should say that schroot appears to have a lot more functionality
> than I previously realized. I had thought it was just a fancy suid
> chroot similar to 'dchroot' adding a security layer around chroot(2).
> But it looks like it can
t; "There is a provision for a "local initscript policy layer" (...),
> which allows the local system administrator to control the behaviour of
> invoke-rc.d for every initscript id and action"
> http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt
Yes.
On Fri, Jul 20, 2012 at 12:48:49PM +, Ramon Hofer wrote:
> On Fri, 20 Jul 2012 10:42:58 +0100, Roger Leigh wrote:
>
> > On Thu, Jul 19, 2012 at 12:34:26PM +, Ramon Hofer wrote:
> >> I have some questions about starting daemons in a chroot environment or
> >>
On Fri, 20 Jul 2012 10:42:58 +0100, Roger Leigh wrote:
> On Thu, Jul 19, 2012 at 12:34:26PM +, Ramon Hofer wrote:
>> I have some questions about starting daemons in a chroot environment or
>> rather about starting schroot on bootup.
>> The reason I want to do this is
epending upon ischroot and ischroot getting it wrong and that
> leaving a broken /run - /var/run behind. You might hit that too.
>
> You should set up a usr/sbin/policy-rc.d script in your chroot.
> Something like this:
>
> #!/bin/sh exit 101
>
> That will prevent installa
On Thu, Jul 19, 2012 at 12:34:26PM +, Ramon Hofer wrote:
> I have some questions about starting daemons in a chroot environment or
> rather about starting schroot on bootup.
> The reason I want to do this is to clean up my server. It's a Squeeze
> with an AMD64 kernel fro
On Thu, Jul 19, 2012 at 09:28:52PM -0600, Bob Proulx wrote:
> Ramon Hofer wrote:
> > Installed sid
> > $ sudo debootstrap sid /srv/chroot/sid/ http://ftp.ch.debian.org/debian/
>
> I haven't submitted a bug yet but I always have problems with sysvinit
> postinst depending upon ischroot and ischroot
/run behind. You might hit that too.
You should set up a usr/sbin/policy-rc.d script in your chroot.
Something like this:
#!/bin/sh
exit 101
That will prevent installations from starting daemons in the chroot.
Or if there is a daemon that you wish to start in the chroot then you
could use a scr
Hi all
I have some questions about starting daemons in a chroot environment or
rather about starting schroot on bootup.
The reason I want to do this is to clean up my server. It's a Squeeze
with an AMD64 kernel from backports. Some packages are from testing which
gives me problems becau
On Tuesday 04 May 2010 04:40:13 exp...@hope.cz wrote:
> I have several running daemons that write some data to files
> What happens with these open files when INIT 6 command is issued?
Depends on the daemon. Prior to a clean reboot, a process is sent the TERM
signal, which it may
their cache. This is written to disk
during filesytem sync.
So these files are preserved. But when the system goes down because of a
power glitch, there are chances that you lose your data from last filesystem
sync.
On Tue, May 4, 2010 at 15:10, wrote:
I have several running daemons that write
down because of a
power glitch, there are chances that you lose your data from last filesystem
sync.
On Tue, May 4, 2010 at 15:10, wrote:
> I have several running daemons that write some data to files
> What happens with these open files when INIT 6 command is issued?
> Are these files
I have several running daemons that write some data to files
What happens with these open files when INIT 6 command is issued?
Are these files that are used by daemons deleted? Or are they closed regularly
and saved ?
And what happens, if the Linux box is shut down in a dirty way( out of
Good day.
I want to run the following list of daemons under normal user - for security
reasons:
saslauthd, couriertcpd, courierpop3login, authdaemond, spamd, logger
could You please share Your opinion on how I can do that - as it is not clear
from its running scripts where to specify it
Manoj Srivastava writes:
>On Thu, Sep 10 2009, Cameron Hutchison wrote:
>> Version 3 (below) is "properly" written, in a functional style. It's much
>> longer, but much easier to read. The main() function is very simple,
>> as is each individual function. It's written in such a way that you
>> c
On Thu, Sep 10 2009, Cameron Hutchison wrote:
> Version 3 (below) is "properly" written, in a functional style. It's much
> longer, but much easier to read. The main() function is very simple,
> as is each individual function. It's written in such a way that you
> can add extra filters if you wan
Javier Barroso writes:
>On Thu, Sep 10, 2009 at 11:33 PM, Cameron Hutchison wrote:
>>
>> /proc/pid/cmdline usually has ASCII NUL separated fields, which awk does
>> not split, so usually you have to use xargs -0. I noticed some cases
>> where the args were space separated (perl script), so I nee
On Fri, 11 Sep 2009, Thomas Dickey wrote:
On Fri, 11 Sep 2009, Thomas Dickey wrote:
however, Debian's packagage maintainer for mawk has not responded to any of
package...
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
To UNSUBSCRIBE, email t
On Fri, 11 Sep 2009, Thomas Dickey wrote:
On Fri, 11 Sep 2009, Javier Barroso wrote:
On Thu, Sep 10, 2009 at 11:33 PM, Cameron Hutchison wrote:
/proc/pid/cmdline usually has ASCII NUL separated fields, which awk does
not split, so usually you have to use xargs -0. I noticed some cases
where
On Fri, 11 Sep 2009, Javier Barroso wrote:
On Thu, Sep 10, 2009 at 11:33 PM, Cameron Hutchison wrote:
/proc/pid/cmdline usually has ASCII NUL separated fields, which awk does
not split, so usually you have to use xargs -0. I noticed some cases
where the args were space separated (perl script),
On Thu, Sep 10, 2009 at 11:33 PM, Cameron Hutchison wrote:
> Javier Barroso writes:
>
>>> is this "xargs: echo: terminated by signal 13" the output it should be?
>>Probably, substituting:
>
>> bin=$(xargs -n 1 -0 echo < /proc/$pid/cmdline | awk '{print $1 ; exit}')
>
>>with
>
>>bin=$(awk '{print
Israel Garcia writes:
>[...] it seems when the script found
>duplicate lines, like named/tcp and named/udp it only show one, se
>below:
>vps204:/usr/local/bin# netstat -lntup
>tcp0 0 67.212.94.125:530.0.0.0:* >LISTEN 23874/named
>tcp0 0 127.0.0.1:53
On 9/10/09, Cameron Hutchison wrote:
> Cameron Hutchison writes:
>
>>Israel Garcia writes:
>>>On 9/10/09, Cameron Hutchison wrote:
>
Version 3 (below) is "properly" written, in a functional style. [...]
>
>>>Well, in version 3 I see no output when I run the script...I double
>>>check but I
Cameron Hutchison writes:
>Israel Garcia writes:
>>On 9/10/09, Cameron Hutchison wrote:
>>> Version 3 (below) is "properly" written, in a functional style. [...]
>>Well, in version 3 I see no output when I run the script...I double
>>check but I dont know where the problem is.
>Hmmm, work fo
Israel Garcia writes:
>On 9/10/09, Cameron Hutchison wrote:
>> Version 3 (below) is "properly" written, in a functional style. [...]
>Well, in version 3 I see no output when I run the script...I double
>check but I dont know where the problem is.
Hmmm, work for me (tm). Try isolating the failu
Javier Barroso writes:
>> is this "xargs: echo: terminated by signal 13" the output it should be?
>Probably, substituting:
> bin=$(xargs -n 1 -0 echo < /proc/$pid/cmdline | awk '{print $1 ; exit}')
>with
>bin=$(awk '{print $1; exit}' /proc/$pid/cmdline)
>will solved the issue
>But I'm not su
ple IP addresses (samba is one).
>> * Skip non-existent processes
>> * remove (delete) from the end of readlink paths. This may happen if a
>> package has been upgraded and the old exe deleted.
>> * Use argv[0] if its an executable instead of /proc/pid/exe. This
&
On 9/10/09, Cameron Hutchison wrote:
> Cameron Hutchison writes:
>
>>Ok. Here's version 2. Fixes are:
>
> One more iteration before I go to bed.
>
> Version 2 was the quickly knocked together script that looks ugly and
> hard to read, but is nice and compact. Maybe "nice" isn't the right
> word.
move (delete) from the end of readlink paths. This may happen if a
> package has been upgraded and the old exe deleted.
> * Use argv[0] if its an executable instead of /proc/pid/exe. This
> makes daemons that are running under interpretters (perl, ruby, etc)
> identified pr
Cameron Hutchison writes:
>Ok. Here's version 2. Fixes are:
One more iteration before I go to bed.
Version 2 was the quickly knocked together script that looks ugly and
hard to read, but is nice and compact. Maybe "nice" isn't the right
word.
Version 3 (below) is "properly" written, in a funct
Israel Garcia writes:
>On 9/9/09, Cameron Hutchison wrote:
>> Israel Garcia writes:
>>
>>>I have more than 10 debian (etch and lenny) servers and I want to find
>>>a way to know remotely on every server:
>>
>>>1. Name of running daemons and por
On 9/9/09, Ron Johnson wrote:
> On 2009-09-09 23:30, Israel Garcia wrote:
>> On 9/9/09, Cameron Hutchison wrote:
>>> Israel Garcia writes:
>>>
>>>> I have more than 10 debian (etch and lenny) servers and I want to find
>>>> a way to know remote
On 2009-09-09 23:30, Israel Garcia wrote:
On 9/9/09, Cameron Hutchison wrote:
Israel Garcia writes:
I have more than 10 debian (etch and lenny) servers and I want to find
a way to know remotely on every server:
1. Name of running daemons and ports (tcp/udp) they're using.
2. Version o
On 9/9/09, Cameron Hutchison wrote:
> Israel Garcia writes:
>
>>I have more than 10 debian (etch and lenny) servers and I want to find
>>a way to know remotely on every server:
>
>>1. Name of running daemons and ports (tcp/udp) they're using.
>>2. Version
Israel Garcia writes:
>I have more than 10 debian (etch and lenny) servers and I want to find
>a way to know remotely on every server:
>1. Name of running daemons and ports (tcp/udp) they're using.
>2. Version of the package (installed by APT) used by these daemons.
>3. V
I have more than 10 debian (etch and lenny) servers and I want to find
a way to know remotely on every server:
1. Name of running daemons and ports (tcp/udp) they're using.
2. Version of the package (installed by APT) used by these daemons.
3. Version of the latest package (from deb mirros)
Michael Biebl wrote:
Hugo Vanwoerkom wrote:
Hugo Vanwoerkom wrote:
Hi,
Since upgrading to the latest Xorg htop shows 60 console-kit-daemons.
Do I need all 60? What do they do?
Actually there are 64 threads all the time. This describes the phenomenon:
http://bbs.archlinux.org/viewtopic.php
On 2009-08-11 21:20, John Hasler wrote:
Ron Johnson writes:
Real Men boot into the console, and use startx to (begrudgingly) enter
X where they then fire up dozens of xterm windows...
Real Men have been using X since it was cool.
Only when big, nice monitors were really expensive, and having
Ron Johnson writes:
> Real Men boot into the console, and use startx to (begrudgingly) enter
> X where they then fire up dozens of xterm windows...
Real Men have been using X since it was cool.
> ...wishing they could purge nautilus and other so called GUI file
> managers ...
Why would they inst
On 2009-08-11 16:05, Charles wrote:
On Tue, 11 Aug 2009 13:25:05 -0500
Ron Johnson wrote:
On 2009-08-11 13:07, Hugo Vanwoerkom wrote:
Michael Biebl wrote:
Hugo Vanwoerkom wrote:
Hugo Vanwoerkom wrote:
Hi,
Since upgrading to the latest Xorg htop shows 60
console-kit-daemons.
///snip
On Tue, 11 Aug 2009 13:25:05 -0500
Ron Johnson wrote:
> On 2009-08-11 13:07, Hugo Vanwoerkom wrote:
> > Michael Biebl wrote:
> >> Hugo Vanwoerkom wrote:
> >>> Hugo Vanwoerkom wrote:
> >>>> Hi,
> >>>>
> >>>>
On Tue, 11 Aug 2009 13:25:05 -0500
Ron Johnson wrote:
> On 2009-08-11 13:07, Hugo Vanwoerkom wrote:
> > Michael Biebl wrote:
> >> Hugo Vanwoerkom wrote:
> >>> Hugo Vanwoerkom wrote:
> >>>> Hi,
> >>>>
> >>>>
On 2009-08-11 13:07, Hugo Vanwoerkom wrote:
Michael Biebl wrote:
Hugo Vanwoerkom wrote:
Hugo Vanwoerkom wrote:
Hi,
Since upgrading to the latest Xorg htop shows 60 console-kit-daemons.
Do I need all 60? What do they do?
Actually there are 64 threads all the time. This describes the
Michael Biebl wrote:
Hugo Vanwoerkom wrote:
Hugo Vanwoerkom wrote:
Hi,
Since upgrading to the latest Xorg htop shows 60 console-kit-daemons.
Do I need all 60? What do they do?
Actually there are 64 threads all the time. This describes the phenomenon:
http://bbs.archlinux.org/viewtopic.php
Hugo Vanwoerkom wrote:
> Hugo Vanwoerkom wrote:
>> Hi,
>>
>> Since upgrading to the latest Xorg htop shows 60 console-kit-daemons.
>>
>> Do I need all 60? What do they do?
>>
>
> Actually there are 64 threads all the time. This describes the phenomenon
Hugo Vanwoerkom wrote:
Hi,
Since upgrading to the latest Xorg htop shows 60 console-kit-daemons.
Do I need all 60? What do they do?
Actually there are 64 threads all the time. This describes the phenomenon:
http://bbs.archlinux.org/viewtopic.php?id=57491
Nobody noticed this? You will
Hi,
Since upgrading to the latest Xorg htop shows 60 console-kit-daemons.
Do I need all 60? What do they do?
Hugo
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi folks--
Is there a recommended "best practice" for specifying the umask for
daemons when running _stable_?
Or how is the umask established for a system user with no login shell?
For example. Even though the default umask is 022, I wish to run
motion(1) as a daemon with um
Ter, 2005-10-25 às 16:07 -0400, Stephen R Laniel escreveu:
> I'm writing a script that will need to run across FreeBSD,
> Debian, Gentoo and probably other machines, and will need to
> tell me, among other things, which daemons would launch at
> startup if the machine were rebo
Stephen R Laniel napisał(a):
I'm writing a script that will need to run across FreeBSD,
Debian, Gentoo and probably other machines, and will need to
tell me, among other things, which daemons would launch at
startup if the machine were rebooted. So I wonder
1) what the best Debian command
I'm writing a script that will need to run across FreeBSD,
Debian, Gentoo and probably other machines, and will need to
tell me, among other things, which daemons would launch at
startup if the machine were rebooted. So I wonder
1) what the best Debian command is to figure this out
On Tue, Jun 07, 2005 at 11:41:23AM +0200, Olaf van der Spek wrote:
> Is it possible for a user to ensure that a certain app is (always)
> started after system start (and stopped before shutdown) without using
> root access?
> If so, how?
Use sudo to give certain users root access to the daemon's b
Hi,
Is it possible for a user to ensure that a certain app is (always)
started after system start (and stopped before shutdown) without using
root access?
If so, how?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Hasler said:
> It won't restart the service if you have left at least one K link in place.
> Debian provides several tools for turning services on and off. My favorite
> is sysvconfig (since I wrote it).
>
thanks, John. I'm checking out sysvcon
/phil writes:
> It does... what? If it checked to see if I've turned off a service...
It won't restart the service if you have left at least one K link in place.
Debian provides several tools for turning services on and off. My favorite
is sysvconfig (since I wrote it).
--
John Hasler
--
To
Phil Dyer wrote:
Nope. Because that is not how it works or has ever worked. Your
expectation is skewed from reality (sorry).
Hate to keep beating this. But my response is:
Just because it's not how it's ever worked doesn't mean it's right. Can
you give me reasoning as to *why* it works like th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Miquel van Smoorenburg said:
>>OK, although both solutions work, (I guess - I haven't tried the second
>>solution) it still seems kludgy to me. If I use the debian supplied tool
>>to remove a service from startup _totally_, and I use a debian supplied
In article <[EMAIL PROTECTED]>,
Phil Dyer <[EMAIL PROTECTED]> wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Miquel van Smoorenburg said:
>
If you want to keep updates from starting the daemon, just chmod 644 it.
>>>
>>>That sounds reasonable...and simple. :) thanks.
>>
>> Reasonable, simple, a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Miquel van Smoorenburg said:
>>> If you want to keep updates from starting the daemon, just chmod 644 it.
>>
>>That sounds reasonable...and simple. :) thanks.
>
> Reasonable, simple, and wrong :)
>
> As long as one start or stop link is still presen
es since these are all just
>> symlinks to a script in /etc/init.d/. All that it probably checks for is
>> that the /etc/init.d/ script exists and is executable. Then,
>> on the assumption that its generally a good idea to stop and start
>> daemons when upgrading them,
Hi List!
I got a question about triggering daemons.
I installed ibm domino server on a debian
sarge. everything works fine, if I log in as the apropriate user and start
the daemon.
As I need the daemon to run at startup,
I wrote an init - script, which is triggered to which I linked from the
.
Several other daemons were also left there after apt-get removing them.
Is this behavior 'by design'? If so, where can I read about it? The man page
insists that apt-get remove is 'identicall to install except that packages
are removed instead of installed'. The behavior I
left /etc/init.d/cpufreqd file there, as well as a link to it in
> rc2.d. Several other daemons were also left there after apt-get
> removing them.
>
> Is this behavior 'by design'?
Ich you use apt-get remove, the configuration files of the package won't
be deleted. And
d
> apt-get remove cpufreqd
try this :
apt-get --purge remove cpufreqd
it might help you -:)
>
> left /etc/init.d/cpufreqd file there, as well as a link to it in rc2.d.
> Several other daemons were also left there after apt-get removing them.
>
> Is this behavior 'by desig
other daemons were also left there after apt-get removing them.
Is this behavior 'by design'? If so, where can I read about it? The man page
insists that apt-get remove is 'identicall to install except that packages
are removed instead of installed'. The behavior I'm exper
1 - 100 of 271 matches
Mail list logo
