Re: killer in the manual

[RalfGesellensetter]

Hi and thanks.

Given the current situation, there is nothing wrong with running killer
once per night (when students should be sleeping). Just the hourly run
caused bad trouble in our setting.

Apropos "left-behind": On our machine, hundreds of ltsp swap files were
left behind (>30 Gig on LTSP:/var) -- is this a unique phenomenon?

Regards
Ralf

Am Thursday, 5. November 2009 schrieb Holger Levsen:

> Hi,
>
> please see and maybe edit:
> http://wiki.debian.org/DebianEdu/Documentation/Lenny/HowTo/Administra
> tion#Automaticcleanupofleft-overprocess
>
> (this is linked from
> http://wiki.debian.org/DebianEdu/Documentation/Lenny/Features)
>
>
> thanks,
> Holger
>

--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ronny Aasen-4]

RalfGesellensetter wrote:
> Hi and thanks.
>
> Given the current situation, there is nothing wrong with running killer
> once per night (when students should be sleeping). Just the hourly run
> caused bad trouble in our setting.
>
> Apropos "left-behind": On our machine, hundreds of ltsp swap files were
> left behind (>30 Gig on LTSP:/var) -- is this a unique phenomenon?
>

Probably  a bug in the script that cleans up left over nbd processes and
files.
more recent nbd deal with this my introducing a timeout feature. but i
do not know if this made its way into lenny. and we can remove the
cleanup scripts.

Ronny Aasen


--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petter Reinholdtsen]

[Ralf Gesellensetter]
> Given the current situation, there is nothing wrong with running
> killer once per night (when students should be sleeping). Just the
> hourly run caused bad trouble in our setting.

Any hope of anyone fixing killer any time soon?  It is in the
debian-edu svn on alioth.  We could perhaps change it to only run once
perb night. :)

> Apropos "left-behind": On our machine, hundreds of ltsp swap files were
> left behind (>30 Gig on LTSP:/var) -- is this a unique phenomenon?

Nope.  We even created a script to clean up that mess until nbd starts
cleaning them up.  See
/usr/share/debian-edu-config/tools/nbdswap-clean.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Holger Levsen-2]

Hi,

On Donnerstag, 5. November 2009, Petter Reinholdtsen wrote:
> > Given the current situation, there is nothing wrong with running
> > killer once per night (when students should be sleeping). Just the
> > hourly run caused bad trouble in our setting.

that would result in less frequent wrong "kills", but still has the potential
of wrong kills. I wouldn't do that. Especially as killer is/was a new package
for lenny, I think we are better of not enabling a half-working feature by
default. It's also documented in the manual now how to enable it if one
really wants it.

> > Apropos "left-behind": On our machine, hundreds of ltsp swap files were
> > left behind (>30 Gig on LTSP:/var) -- is this a unique phenomenon?
> Nope.  We even created a script to clean up that mess until nbd starts
> cleaning them up.  See
> /usr/share/debian-edu-config/tools/nbdswap-clean.

Shouldnt we put this in cron? Also, the manual recommends to use 512mb sized
swap files for workstations with 256mb ram, currently we create 32mb sized
swapfiles. This is suitable for thin-clients but quite useless for diskless
workstations - shouldn't we raise this? (For this we would probably need to
raise harddisc requierments again, but I dont see that as such a big
problem.)


regards,
        Holger

[Petter Reinholdtsen]

[Holger Levsen]
> that would result in less frequent wrong "kills", but still has the
> potential of wrong kills. I wouldn't do that. Especially as killer
> is/was a new package for lenny, I think we are better of not
> enabling a half-working feature by default. It's also documented in
> the manual now how to enable it if one really wants it.

The killer program was introduced to fix problems reported at schools,
with leftover processes and running out of resources.  I hope we can
make sure the lenny release fixes this problem, as it affect a lot of
schools.

Another approach would be to teack killer to look for host group
membership, and only run when the current host is in a group.  It
would allow schools to enable it on single hosts using lwat and LDAP
group memberships.

> Shouldnt we put this in cron? Also, the manual recommends to use
> 512mb sized swap files for workstations with 256mb ram, currently we
> create 32mb sized swapfiles. This is suitable for thin-clients but
> quite useless for diskless workstations - shouldn't we raise this?
> (For this we would probably need to raise harddisc requierments
> again, but I dont see that as such a big problem.)

As far as I know, there is no need to change this.  The thin clients
will ask for more swap when running out, and the swap will be added in
32MB increments. :)

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Holger Levsen-2]

Hi,

On Donnerstag, 5. November 2009, Petter Reinholdtsen wrote:
> > that would result in less frequent wrong "kills", but still has the
> > potential of wrong kills. I wouldn't do that. Especially as killer
> > is/was a new package for lenny, I think we are better of not
> > enabling a half-working feature by default. It's also documented in
> > the manual now how to enable it if one really wants it.
> The killer program was introduced to fix problems reported at schools,
> with leftover processes and running out of resources.  I hope we can
> make sure the lenny release fixes this problem, as it affect a lot of
> schools.

Schools which have this issues can follow
http://wiki.debian.org/DebianEdu/Documentation/Lenny/HowTo/Administration#Automaticcleanupofleft-overprocess

> Another approach would be to teack killer to look for host group
> membership, and only run when the current host is in a group.  It
> would allow schools to enable it on single hosts using lwat and LDAP
> group memberships.

Do you really think this will happen soon enough to be included in our lenny
release? Assuming we release lenny this year....

> > Shouldnt we put this in cron? Also, the manual recommends to use
> > 512mb sized swap files for workstations with 256mb ram, currently we
> > create 32mb sized swapfiles. This is suitable for thin-clients but
> > quite useless for diskless workstations - shouldn't we raise this?
> > (For this we would probably need to raise harddisc requierments
> > again, but I dont see that as such a big problem.)
>
> As far as I know, there is no need to change this.  The thin clients
> will ask for more swap when running out, and the swap will be added in
> 32MB increments. :)

The we should probably reword the stuff about swap in
http://wiki.debian.org/DebianEdu/Documentation/Lenny/Requirements#Hardwarerequirements
?!


regards,
        Holger

[RalfGesellensetter]

Am Thursday, 5. November 2009 schrieb Petter Reinholdtsen:
> [Ralf Gesellensetter]
>
> > Given the current situation, there is nothing wrong with running
> > killer once per night (when students should be sleeping). Just the
> > hourly run caused bad trouble in our setting.
>
> Any hope of anyone fixing killer any time soon?  It is in the
> debian-edu svn on alioth.  We could perhaps change it to only run
>  once perb night. :)

Hi there, I did "read" the script - which has a lot of "comments" -
which are actually the source for the man page - but I missed those
comments that could have led me to the section where anonymous processes
are killed. :/ Any perl wizzard following? Have a look at the tarball at
http://ftp.skolelinux.no/debian/pool/main/k/killer/ - please! [1]
>
> > Apropos "left-behind": On our machine, hundreds of ltsp swap files
> > were left behind (>30 Gig on LTSP:/var) -- is this a unique
> > phenomenon?
>
> Nope.  We even created a script to clean up that mess until nbd
>  starts cleaning them up.  See
> /usr/share/debian-edu-config/tools/nbdswap-clean.

Yes, this script is there; also nightkill.sh which could be an
alternative to killer. Anyway debian-edu-config seems to be the right
package to place such maintainance scripts.
>
> Happy hacking,
>

Please follow recent IRC log on #debian-edu to find some alternative
approaches on clearing left-behind processes deliberately (rather than
killing arbitrary unidentified processes).

Regards
Ralf

P.S.: I dare place a copy of the "killer" perl script to Debian pastebin
- so you perl wizzards can find a way to regard user IDs of logged in
users (-> last; who). It's on:
[1] http://ftp.skolelinux.no/debian/pool/main/k/killer/


--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[RalfGesellensetter]

Am Thursday, 5. November 2009 schrieb RalfGesellensetter:
> Please follow recent IRC log on #debian-edu to find some alternative
> approaches on clearing left-behind processes deliberately (rather
>  than  killing arbitrary unidentified processes).


Dear list, only now I find the time to sumarize some thoughts from IRC:

<RalfG> h01ger: I start to understand what you dislike about killer. It
kills processes not on purpose, but arbitrary -- like a redneck
(alternative package name?) shooting at everything that doesn't match
his patterns.
<RalfG> I tend to agree that this approach is "bad" as it must fail as
soon as you introduce new roles unknown to killer.

<RalfG> On contrary, the clean-up-left-behind-processes-after-logout-
script should follow a simple and clean policy like this:
<RalfG> get a list of users who were logged in today - and if they
aren't logged in anymore, kill _their_ processes.
<RalfG> all needed for this can be found (again) in last.
<RalfG> alternatively, you could follow /var/log/auth.log and wait for
"logout" messages. But this log is on tjener, I think.

<RalfG> Yet another approach could be to have processes of users killed,
that are member in a given group (student) unless they are still logged
in.

<RalfG> h01ger: this command shows all user sessions that have been
closed today:
grep "session closed" /var/log/auth.log |grep -v "user root" | grep -v  
\ "user daemon" | grep -v "user nobody" |grep "`LANG=C date +"%b %_d"`"
\|cut "-d " -f12 |sort -u | grep ... | tr '[A-Z]' '[a-z]'

<RalfG> Now find users who are still logged in:
LANG=C last |grep "still logged in" | cut "-d " -f1 | sort -u

<RalfG> note: here might be ambigious names as logins are truncated to 8
characters.
<RalfG> Now I could do a "grep -v" on every line there to remove still
logged in users...

<RalfG> rather than triggering the clean-up-left-behind-processes-after-
logout-script every hour, wouldn't it be great just to write a watchdog
for auth.log - something like "tail -f /var/log/auth.log" that issues a
pkill whenever a (regular) user closes their sessioN?
<RalfG> of course, this would mean, that all processes are killed of one
of several sessions owned by the same user is closed (unless
doublechecking "who").
<RalfG> and, of course, this script should not regard old entries in
auth.log in case it is started much after boot time

Now, I think a combination of both should be possible (do the filtering
on tail -f) -- and yes, of course, users who are permanently logged in
will not be regarded (maybe by nightkill in debian-edu-config?).

There was also a discussion that virtually the session manager (like
LDM) should do the job in a propper way, but then, there is also KDM and
GDM, and it is hard to convince their upstreams to find a common way of
purging closed sessions. Hence the watchdog for auth.log seems to be a
straight forward way to go (to me), what do you think?

First steps could be auxialary scripts like test-if-user-is-logged-in
(checking in who).

Then I wonder, if there isn't a mother process to all processes run
within a session, so that the only thing to do is killing this embedding
process at logout time?


--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[José "L. Redrejo" Rodríguez]

El jue, 05-11-2009 a las 20:23 +0100, RalfGesellensetter escribió:

> Am Thursday, 5. November 2009 schrieb RalfGesellensetter:
> > Please follow recent IRC log on #debian-edu to find some alternative
> > approaches on clearing left-behind processes deliberately (rather
> >  than  killing arbitrary unidentified processes).
>
>
> Dear list, only now I find the time to sumarize some thoughts from IRC:
>
> <RalfG> h01ger: I start to understand what you dislike about killer. It
> kills processes not on purpose, but arbitrary -- like a redneck
> (alternative package name?) shooting at everything that doesn't match
> his patterns.
> <RalfG> I tend to agree that this approach is "bad" as it must fail as
> soon as you introduce new roles unknown to killer.
>
> <RalfG> On contrary, the clean-up-left-behind-processes-after-logout-
> script should follow a simple and clean policy like this:
> <RalfG> get a list of users who were logged in today - and if they
> aren't logged in anymore, kill _their_ processes.
> <RalfG> all needed for this can be found (again) in last.
> <RalfG> alternatively, you could follow /var/log/auth.log and wait for
> "logout" messages. But this log is on tjener, I think.
>
> <RalfG> Yet another approach could be to have processes of users killed,
> that are member in a given group (student) unless they are still logged
> in.
>
> <RalfG> h01ger: this command shows all user sessions that have been
> closed today:
> grep "session closed" /var/log/auth.log |grep -v "user root" | grep -v  
> \ "user daemon" | grep -v "user nobody" |grep "`LANG=C date +"%b %_d"`"
> \|cut "-d " -f12 |sort -u | grep ... | tr '[A-Z]' '[a-z]'
>
> <RalfG> Now find users who are still logged in:
> LANG=C last |grep "still logged in" | cut "-d " -f1 | sort -u
>
> <RalfG> note: here might be ambigious names as logins are truncated to 8
> characters.
> <RalfG> Now I could do a "grep -v" on every line there to remove still
> logged in users...
>
> <RalfG> rather than triggering the clean-up-left-behind-processes-after-
> logout-script every hour, wouldn't it be great just to write a watchdog
> for auth.log - something like "tail -f /var/log/auth.log" that issues a
> pkill whenever a (regular) user closes their sessioN?
> <RalfG> of course, this would mean, that all processes are killed of one
> of several sessions owned by the same user is closed (unless
> doublechecking "who").
> <RalfG> and, of course, this script should not regard old entries in
> auth.log in case it is started much after boot time
>
> Now, I think a combination of both should be possible (do the filtering
> on tail -f) -- and yes, of course, users who are permanently logged in
> will not be regarded (maybe by nightkill in debian-edu-config?).
>
> There was also a discussion that virtually the session manager (like
> LDM) should do the job in a propper way, but then, there is also KDM and
> GDM, and it is hard to convince their upstreams to find a common way of
> purging closed sessions. Hence the watchdog for auth.log seems to be a
> straight forward way to go (to me), what do you think?
>
> First steps could be auxialary scripts like test-if-user-is-logged-in
> (checking in who).
>
> Then I wonder, if there isn't a mother process to all processes run
> within a session, so that the only thing to do is killing this embedding
> process at logout time?

Just in case it might help: Last year when I given up using killer
because of it killing ssh sessions, I implemented that kind of routine
in ControlAula.
In http://paste.debian.net/50868/ you can see the code (for 72 hours
since now)

When using gnome, one of the common zombie processes is gnome-panel, if
an user logins with gnome-panel running as a zombie with his own login,
the desktop is totally broken, so ControlAula is calling this killer()
routine with a watch timer every 10 seconds.

The approach is similar to yours, but using 'who' instead of 'last'. It
just gets a list of the logged users and another list with the logged
processes with their user id. It compares them and kills all the
processes whose uid are not logged and between 1000 and 65535 (to avoid
killing services and processes launched under the "nobody" user).
It's quite simple and has been working perfectly for our purposes for
about a year in our schools.

Regards.

[José "L. Redrejo" Rodríguez]

El vie, 06-11-2009 a las 09:32 +0100, José L. Redrejo Rodríguez
escribió:

> El jue, 05-11-2009 a las 20:23 +0100, RalfGesellensetter escribió:
> > Am Thursday, 5. November 2009 schrieb RalfGesellensetter:
> > > Please follow recent IRC log on #debian-edu to find some alternative
> > > approaches on clearing left-behind processes deliberately (rather
> > >  than  killing arbitrary unidentified processes).
> >
> >
> > Dear list, only now I find the time to sumarize some thoughts from IRC:
> >
> > <RalfG> h01ger: I start to understand what you dislike about killer. It
> > kills processes not on purpose, but arbitrary -- like a redneck
> > (alternative package name?) shooting at everything that doesn't match
> > his patterns.
> > <RalfG> I tend to agree that this approach is "bad" as it must fail as
> > soon as you introduce new roles unknown to killer.
> >
> > <RalfG> On contrary, the clean-up-left-behind-processes-after-logout-
> > script should follow a simple and clean policy like this:
> > <RalfG> get a list of users who were logged in today - and if they
> > aren't logged in anymore, kill _their_ processes.
> > <RalfG> all needed for this can be found (again) in last.
> > <RalfG> alternatively, you could follow /var/log/auth.log and wait for
> > "logout" messages. But this log is on tjener, I think.
> >
> > <RalfG> Yet another approach could be to have processes of users killed,
> > that are member in a given group (student) unless they are still logged
> > in.
> >
> > <RalfG> h01ger: this command shows all user sessions that have been
> > closed today:
> > grep "session closed" /var/log/auth.log |grep -v "user root" | grep -v  
> > \ "user daemon" | grep -v "user nobody" |grep "`LANG=C date +"%b %_d"`"
> > \|cut "-d " -f12 |sort -u | grep ... | tr '[A-Z]' '[a-z]'
> >
> > <RalfG> Now find users who are still logged in:
> > LANG=C last |grep "still logged in" | cut "-d " -f1 | sort -u
> >
> > <RalfG> note: here might be ambigious names as logins are truncated to 8
> > characters.
> > <RalfG> Now I could do a "grep -v" on every line there to remove still
> > logged in users...
> >
> > <RalfG> rather than triggering the clean-up-left-behind-processes-after-
> > logout-script every hour, wouldn't it be great just to write a watchdog
> > for auth.log - something like "tail -f /var/log/auth.log" that issues a
> > pkill whenever a (regular) user closes their sessioN?
> > <RalfG> of course, this would mean, that all processes are killed of one
> > of several sessions owned by the same user is closed (unless
> > doublechecking "who").
> > <RalfG> and, of course, this script should not regard old entries in
> > auth.log in case it is started much after boot time
> >
> > Now, I think a combination of both should be possible (do the filtering
> > on tail -f) -- and yes, of course, users who are permanently logged in
> > will not be regarded (maybe by nightkill in debian-edu-config?).
> >
> > There was also a discussion that virtually the session manager (like
> > LDM) should do the job in a propper way, but then, there is also KDM and
> > GDM, and it is hard to convince their upstreams to find a common way of
> > purging closed sessions. Hence the watchdog for auth.log seems to be a
> > straight forward way to go (to me), what do you think?
> >
> > First steps could be auxialary scripts like test-if-user-is-logged-in
> > (checking in who).
> >
> > Then I wonder, if there isn't a mother process to all processes run
> > within a session, so that the only thing to do is killing this embedding
> > process at logout time?
>
>
> Just in case it might help: Last year when I given up using killer
> because of it killing ssh sessions, I implemented that kind of routine
> in ControlAula.
> In http://paste.debian.net/50868/ you can see the code (for 72 hours
> since now)
>
> When using gnome, one of the common zombie processes is gnome-panel, if
> an user logins with gnome-panel running as a zombie with his own login,
> the desktop is totally broken, so ControlAula is calling this killer()
> routine with a watch timer every 10 seconds.
>
> The approach is similar to yours, but using 'who' instead of 'last'. It
> just gets a list of the logged users and another list with the logged
> processes with their user id. It compares them and kills all the
> processes whose uid are not logged and between 1000 and 65535 (to avoid
> killing services and processes launched under the "nobody" user).
> It's quite simple and has been working perfectly for our purposes for
> about a year in our schools.
>
> Regards.
>

I've almost forgot it: using who instead of last, you don't have the 8
chars limit in the login names.

[Vagrant Cascadian]

On Thu, Nov 05, 2009 at 11:18:17AM +0100, Petter Reinholdtsen wrote:
> [Holger Levsen]
> > Shouldnt we put this in cron? Also, the manual recommends to use
> > 512mb sized swap files for workstations with 256mb ram, currently we
> > create 32mb sized swapfiles. This is suitable for thin-clients but
> > quite useless for diskless workstations - shouldn't we raise this?
> > (For this we would probably need to raise harddisc requierments
> > again, but I dont see that as such a big problem.)

maybe i'm wrong, but i can't imagine a machine using that much swap over an NBD
device would be useable.
 
> As far as I know, there is no need to change this.  The thin clients
> will ask for more swap when running out, and the swap will be added in
> 32MB increments. :)

really? how is this accomplished?

i also seem to recall that in debian-edu swap files were hard-coded based on ip
address...  this would mean that multiple requests for a swap file would result
in the same exact file, which wouldn't work well for swap.

time to go digging into the code...

live well,
  vagrant


--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[RalfGesellensetter]

Am Friday, 6. November 2009 schrieb José "L. Redrejo" Rodríguez:
> I've almost forgot it: using who instead of last, you don't have the
>  8 chars limit in the login names.

Dear José,

thank you for sharing your interesting script
(and supporting my approach this way).
It is charmingly short - thanks to the power of Gambas
(even more charming!).

I think I remember that it is not a big deal anymore to meet
the dependencies for running Gambas script - so I'd suggest
to add the package needed (gambas2-runtime?), as it won't be trivial
to tranlate your script to a shell [perl] script!?

Kind regards,
Ralf


--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[RalfGesellensetter]

Am Friday, 6. November 2009 schrieb RalfGesellensetter:
> Dear José,
>
> thank you for sharing your interesting script
> (and supporting my approach this way).
> It is charmingly short - thanks to the power of Gambas
> (even more charming!).

As your script is quite short - and most likely under GPL,
I dare attach it to this mail - so everybody can see the
nice syntax of Gambas Basic.

I might be able to test the script next Friday.
>
> I think I remember that it is not a big deal anymore to meet
> the dependencies for running Gambas script - so I'd suggest
> to add the package needed (gambas2-runtime?), as it won't be trivial
> to tranlate your script to a shell [perl] script!?

I remember that the Gambas IDE has an export filter to Debian packages.
Assuming that all dependencies are set as needed, it shouldn't be a big
deal to provide a first package for this.

Sometimes, prolongued peeking pays off ;)

Regards & thanks again
Ralf

STATIC PUBLIC SUB KillAllChildren(PPID AS Integer)
DIM result AS String
DIM bits AS String[]
DIM child AS String
  SHELL "ps -A -o %p,%P|grep " & CStr(PPID) & "|cut -f1 -d," TO result
  bits = Split(result, "\n")
  FOR EACH child IN bits
    TRY SHELL "kill -9 " & child & " 2>/dev/null"
  NEXT  
END

STATIC PUBLIC SUB Killer()
DIM pids AS String[]
DIM uids AS Collection
DIM bits AS String[]
DIM tmpShell AS String
DIM sTmp AS String
DIM uid AS Integer

'get logged users:
  SHELL "who|cut -f1 -d\" \"|uniq" TO tmpShell
  bits = Split(Trim$(tmpShell), "\n")
  IF bits.Count = 0 THEN RETURN
  uids = NEW Collection(gb.Text)
  FOR EACH sTmp IN bits
    SHELL "getent passwd " & sTmp & "|cut -f3 -d:" TO tmpShell 'this works even with ldap users
    tmpShell = Trim$(tmpShell)
    TRY uids.Add(sTmp, tmpShell)
  NEXT
 
'get current processes
  SHELL "ps -e -o euid= -o pid=|tr -s \" \"" TO tmpShell
  pids = Split(Trim$(tmpShell), "\n")
  FOR EACH sTmp IN pids
    bits = Split(Trim$(sTmp), " ")
    IF bits.Count < 2 THEN CONTINUE
    uid = CInt(bits[0])
    'uid's under 1000 are ignored and nobody user too, as it's used by some needed daemons:
    IF uid >= 1000 AND uid <> 65534 AND NOT uids.Exist(bits[0]) THEN
       TRY KillAllChildren(CInt(bits[1]))
       IF Utils.Debugging THEN PRINT "\\\\\\Killed: " & bits[1] & " of " & bits[0]
    ENDIF
  NEXT
   
END

[José "L. Redrejo" Rodríguez]

El dom, 08-11-2009 a las 14:13 +0100, RalfGesellensetter escribió:

> Am Friday, 6. November 2009 schrieb RalfGesellensetter:
> > Dear José,
> >
> > thank you for sharing your interesting script
> > (and supporting my approach this way).
> > It is charmingly short - thanks to the power of Gambas
> > (even more charming!).
>
> As your script is quite short - and most likely under GPL,
> I dare attach it to this mail - so everybody can see the
> nice syntax of Gambas Basic.
>
> I might be able to test the script next Friday.
> >
> > I think I remember that it is not a big deal anymore to meet
> > the dependencies for running Gambas script - so I'd suggest
> > to add the package needed (gambas2-runtime?), as it won't be trivial
> > to tranlate your script to a shell [perl] script!?
>
> I remember that the Gambas IDE has an export filter to Debian packages.
> Assuming that all dependencies are set as needed, it shouldn't be a big
> deal to provide a first package for this.
>
> Sometimes, prolongued peeking pays off ;)
>
> Regards & thanks again
> Ralf

You've been faster than me ;)

As many people don't feel confident with gambas I have translated the
script into python. It's attached to this email. For this script to
work, it must be executed as root.

Consider it as a draft to a possible and more elegant solution. I think
that some config options should be added to it.
Now if you want to run it in background, you have to execute:
killer.py &
And if you want to change the time between "killings", the line at the
end with
time.sleep(5)
should change the 5 seconds to any other name.

Anyway, I've tested it a little bit and seems to work exactly as the
gambas version we've been running for a long time.

On the other hand, in Debian lenny there is a gambas package called:
gambas2-script, installing it you can run any gambas code as the
previous one, just adding:
#!/usr/bin/env gbs2
as the first line of the text file (and giving exec permissions to the
file)

Hope this helps.
Regards


[killer.py]

---

#!/usr/bin/env python
# -*- coding: utf-8 -*-
##############################################################################
# Project:     Killer
# Module:     killer.py
# Purpose:     First draft of a simple killer.
# Language:    Python 2.5
# Date:        8-Nov-2009.
# Ver:        28-Nov-2009.
# Author:    José L. Redrejo Rodríguez
# Copyright:   2009 - José L. Redrejo Rodríguez    <jredrejo @nospam@ debian.org>
#
# killer.py is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# HMIServer is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with killer.py. If not, see <http://www.gnu.org/licenses/>.
#
##############################################################################


import sys,os
import signal
import time
import commands


class Killer():        
   
    def _getLoggedUsers(self):
        logged=commands.getoutput("who|cut -f1 -d' '|uniq" )
        loggedusers=logged.splitlines()
        uids={}
        if len(loggedusers) != 0:
            for user in loggedusers:
                newID=commands.getoutput("getent passwd " + user + "|cut -f3 -d:")
                uids[newID]=user
                 
        return uids
                   
    def searchZombies(self):
        print "searching targets"
        uids=self._getLoggedUsers()
        processes=commands.getoutput("ps -e -o euid= -o pid=|tr -s ' '")    
        pids=processes.splitlines()
        for line in pids:
            bits=line.split()
            if len(bits)>2:
                continue
            uid=int(bits[0])
            if uid>=1000 and uid<>65534 and not uids.has_key(bits[0]):
                self._killAllChildren(bits[1])
           
       
       
    def _killAllChildren(self,ppid):
        result=commands.getoutput("ps -A -o %p,%P|grep " + ppid  + "|cut -f1 -d,")
        for child in result.splitlines():
            os.system ("kill -9 " + child + " 2>/dev/null")
 

def handler(signum, frame):
    print 'No more murders today'
    sys.exit()

signal.signal(signal.SIGINT, handler)

myKiller=Killer()


while True:
    time.sleep(5)
    myKiller.searchZombies()

---

[Petter Reinholdtsen]

[José L. Redrejo Rodríguez]
> As many people don't feel confident with gambas I have translated
> the script into python. It's attached to this email. For this script
> to work, it must be executed as root.

Very nice.  Perhaps we should replace the implementation in the killer
package with this one?  Perhaps add support for reporting which
processes are killed to the user or syslog, to get more of the
features of the old killer program.

>         if len(loggedusers) != 0:
>             for user in loggedusers:
>                 newID=commands.getoutput("getent passwd " + user + "|cut -f3 -d:")
>                 uids[newID]=user

One report of failure with the killer package is when the LDAP server
is overloaded and fail to return user information.  Could it be an
idea to try several times to look up user information if getent fail
to return any information?

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[José "L. Redrejo" Rodríguez]

El dom, 08-11-2009 a las 20:00 +0100, Petter Reinholdtsen escribió:

> [José L. Redrejo Rodríguez]
> > As many people don't feel confident with gambas I have translated
> > the script into python. It's attached to this email. For this script
> > to work, it must be executed as root.
>
> Very nice.  Perhaps we should replace the implementation in the killer
> package with this one?  Perhaps add support for reporting which
> processes are killed to the user or syslog, to get more of the
> features of the old killer program.
>

Sure, that's one of the needed things. Also, this should also be
"daemonized"

> >         if len(loggedusers) != 0:
> >             for user in loggedusers:
> >                 newID=commands.getoutput("getent passwd " + user + "|cut -f3 -d:")
> >                 uids[newID]=user
>
> One report of failure with the killer package is when the LDAP server
> is overloaded and fail to return user information.  Could it be an
> idea to try several times to look up user information if getent fail
> to return any information?
>

do you have any idea of a practical time interval to wait between
requests?


> Happy hacking,
> --
> Petter Reinholdtsen
>
>

[Petter Reinholdtsen]

[José L. Redrejo Rodríguez]
> Sure, that's one of the needed things. Also, this should also be
> "daemonized"

Perhaps, or just run from cron.  The latter is easier, but require
cron to be functional. :)

> do you have any idea of a practical time interval to wait between
> requests?

Not sure what is needed to maximize the changes of success, but I
would go with 3 tries with 5 seconds between them, and hope that was
enough.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jonas Smedegaard]

On Mon, Nov 09, 2009 at 01:07:24PM +0100, Petter Reinholdtsen wrote:

>[José L. Redrejo Rodríguez]
>> Sure, that's one of the needed things. Also, this should also be
>> "daemonized"
>
>Perhaps, or just run from cron.  The latter is easier, but require
>cron to be functional. :)
>
>> do you have any idea of a practical time interval to wait between
>> requests?
>
>Not sure what is needed to maximize the changes of success, but I
>would go with 3 tries with 5 seconds between them, and hope that was
>enough.

If it is known what causes unreliability - e.g. LDAP sometimes
unresponsive - then perhaps extend the script to do e.g. simple direct
LDAP queries to verify if getent responses are likely to be reliable.

(sorry if I misunderstood - I haven't followed this thread closely).


  - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: [phone]  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

[José "L. Redrejo" Rodríguez]

El lun, 09-11-2009 a las 14:12 +0100, Jonas Smedegaard escribió:

> On Mon, Nov 09, 2009 at 01:07:24PM +0100, Petter Reinholdtsen wrote:
> >[José L. Redrejo Rodríguez]
> >> Sure, that's one of the needed things. Also, this should also be
> >> "daemonized"
> >
> >Perhaps, or just run from cron.  The latter is easier, but require
> >cron to be functional. :)
> >
> >> do you have any idea of a practical time interval to wait between
> >> requests?
> >
> >Not sure what is needed to maximize the changes of success, but I
> >would go with 3 tries with 5 seconds between them, and hope that was
> >enough.
>
> If it is known what causes unreliability - e.g. LDAP sometimes
> unresponsive - then perhaps extend the script to do e.g. simple direct
> LDAP queries to verify if getent responses are likely to be reliable.
>
> (sorry if I misunderstood - I haven't followed this thread closely).

I think that, as getent request are done via nscd that's caching data,
You have two scenaries:
- ldap might be having a bad moment, but the data can be got through
nscd
- ldap might respond to a query, but a few milliseconds later be
unresponsive and getent through nscd through nslcd might fail.
So, two or three tries seems safer for me to be (aprox) sure the server
is unresponsive.

[RalfGesellensetter]

Am Monday, 9. November 2009 schrieb José "L. Redrejo" Rodríguez:
> do you have any idea of a practical time interval to wait between
> requests?
>

Hi, 5-10 seconds should be tight enough to assume that a user having
logged out recently didn't log in meanwhile.

Also, this interval should be fair enough to spot zombies where getent
failed for the 1st trial.

The only alternative to an interval solution would be
"tail -f" of auth.log as I think.

Regards
Ralf

P.S.: Making this a re-write of killer is probably the most radical
decision - but if you make it happen - I won't complain. As the code is
totally new, launching a brand new package could also be an option (but
probably take longer to make it into Debian).

To be on the safe side, I don't see any reasons against putting the
script into the tools directory of debian-edu-config as well... Just to
make sure it will be in the release to come.


--
To UNSUBSCRIBE, email to debian-edu-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...