yeha your right
can It be configured so that it dose not start a new instance for every process
programs like ls certainly don't need udev or another instance of a wrapper for udev
and what is the over head ( time wise ) in starting another instance of udev+consol-kit for each command when running scripts
what about running out of process numbers what happens then ?

Dunno. A thread is supposed to be very light weight (and I'll bet that most of them are sitting on a mutex waiting for an event to show up) so I'm not sure that it crossed anyone's mind to make that configurable. At some point, you need to keep track of what's going on and in some cases the logic is easier if you dedicate a thread to watch a specific process.

You're getting a new thread in the console-kit-daemon which shouldn't have much to do with udevd. (I see 3 udevd processes running on my machine with no addition threads.) Threads are cheap, that's why you use them instead of fork-and-exec.

You'd have to have 32K things running at the same time for that to happen. You'd probably notice your system slowing down at 20K.

Seems to me that you actually don't know about the security implications, unless you run no browser or any other software accessing the net. A firewall will not prevent drive-by infections or malware aimed at Java, Flash or other browser plugins.

I'm up to process number 31440
the threads don't seem to die when the program they were opened for die they just keep piling up it's like 9 pages of consol-kit and 9 pages of udev running in htop

from reading the consol-kit DOCs it's a layer over udev

What version of slackware are you running?

What does the command output?

I'm running Slackware64 14.1 and I get 549 when I run that command (with XFCE as my window manager and 2 virtual machines running in the background).

yes i know
flash is a horrid thing and id be happy for it to die
and firefox is huge and does execute foreign code

i program every once in a while, so i use htop and even perf top
if anything started using the cpu too much, id notice

i also use wavemon to check if the wireless card started acting up again (it has minor power issues)
so that covers botnets and the like

in the years running slackware so far i haven't noticed anything even hinting of the system being compromised
then again i don't keep any important data on a computer
(people, don't read any of this as security advice. any of it at all)

to be honest i kinda miss the old XP viruses
3 random named processes backed up by 2 weird named executables
i think it was cute
for all the damage viruses do, they do show how many things are possible with operating systems

threads in userspace linux are implemented using clone()
so shared between them is anything mmap'ed (with share flag), like libraries and idk maybe for IPC, files or something
what is not shared is the code segment, data segment and anything malloc'ed
(haven't checked some details on that, like about the code segment, but it should be like that)

shared libraries get mmaped in on exec() anyway by the loader

i could swear it ran a new process every time as i remember knowing back then to set up htop to not show threads
maybe they changed it, maybe i remember wrong

oh well

See http://www.linuxforu.com/2011/08/lig...linux-threads/

When I installed Slackware 14.1 with Xfce, I omitted console-kit from the installation. Runs fine without it, but as ReaperX7 said "Without it you'd have to relog as root each time you'd want to reboot or shutdown the system." Not a big deal to me, and RAM/processes saved.

I don't actually mean to contribute to hijacking a thread, but this tangent is interesting. What has me puzzled is why anyone would desire to run more or less continuously as root on Slackware? Unlike many distros you actually have a root account with a password and don't have to rely on "sudo". It is pretty effortless to login one time as root and choose a different look so that one can tell which graphic apps are root and which are user, and then login from then on as user and use "kdesu" or the gnome equivalent. (Sorry I can't recall it's name. Never liked Gnome and over time I like it even less)

Why even take a chance at such a risk when Slack makes it so easy to avoid it?

although what you link is for the theoretical pthreads (linux gives threads new PIDs, unlike the article suggests) i do correct myself
(i read about pthreads a long time ago, so my bad)

pthreads share everything except the stack
still console-kit NEEDS to store per thread specific data (on the stack, as if it were to be done with malloc the malloced data would be shared across threads but not really useful to any thread but that what malloced it)

also the scheduler has to evaluate every process once per epoh
that is not much overhead but still

anyway i think spawning threads that do not ever exit to be a bad thing


PS i found this to be more detailed

in my case the question is "what risk"
i do not have any sensitive data or i would protect it
and i like fiddling with advanced kernel thingies
(concrete example: i have a script to reset my wireless card when it goes nuts (the card, not just the connection), it uses modprobe)
if i just used my computer to play games and use firefox, id still have windows xp

to derail a bit more
i hate when people write programs assuming their users are idiots
like xmms2 that you need to run with --yes-run-as-root (something with feet too)
or worse 0ad that you (by that i mean I) have to set SUID to run

i knew there will be lots of people assuming i'm an idiot for running as root
understand that i use linux exclusively for... since warcraft 3 frozen throne came out
and i never had problems with viruses, maleware or other malicious code
(lies, i installed a newer ubuntu once)

to derail even more, i have a story about security:
so i installed fedora some time ago
after install i upgraded it and found one program not to work anymore
ok, i thought, il find out why
program used some other program that wouldn't start 'cuz its config file didn't upgrade properly (syntax changed a bit, breaking one line)
so i logged in as root (config was a system one) and went to fix it
god forbid i fix something, for selinux locked the whole system yelling "A FILE HAS CHANGED"
instead of reading whole books about how fedora does things, i installed slackware on that computer

and i still don't think slackware is less secure then fedora

edit: PS i think the author got good answers by a couple knowledgeable people

The RAM/Process of ConsoleKit should technically only be a few KB at best with 0-1% process usage. It's a daemon service only, so it shouldn't even impact the system at all, if ever. It actually should hold one of the smaller footprints as it's only used during login, x-session startup, and logout/shutdown. On modern systems it practically invisible to the standard observer and you technically can't even base an accurate statement that removing/omitting it has an impact.

Unless you're on a system with less than 266MHz processing speed and less than 64MB of RAM, getting an accurate measure of ConsoleKit's impact is going to next to pointless.

My suggestion, it's a near-zero impact service daemon, so unless you're hellbent on locking out users from the reboot/shutdown init level services, leave the bloody thing alone.

The only reason ConsoleKit could have high usage would be multiple logins executing at once, so unless your system is in fact a server used by multiple users on a network, you might want to start looking into who and what could be generating logins or attempted connections to your PC.

1 members found this post helpful.