Det kan du nok ordne det sådan her.
- Dit scripts skal startes med root rettigheder.
- Det første scriptet gør er at det kører renice på sit eget proces id (pid), som giver dit program mere procestid end alle andre programmer, og derfor kører færdig før de fleste andre programmer. -5 til -7 ekstra bør være nok.
renice manual side:http://manpages.ubuntu.com/manpages/maverick/en/man1/renice.1.html - I punkt 4 dropper scriptet derefter sine root privillegier, fordi det ikke længere har brug for dem. Det gør den ved at det skifte til dit brugernavn. (su kommandoen bruges)
- Til sidst kører dine kommandoer:
Kode: Vælg alt
su <brugernavn> -c "kode/script-der-skal-køres-som-en-anden-bruger"
Det ville måske være bedst at køre dit script fra en lille C wrapper der skifter hastighed (renicer scriptets prioritiet), når scriptet er startet.
Et oversat program (C wrapperen) kan man køre SET UID root, så det kan startes op af dig som alm bruger uden brug af sudo for at få root rettigheder.
Jeg har også brug for sådan en wrapper, så her er nogle noter til mig selv (programkode vil blive lagt i nyt indlæg i Sandkassen og nok også på github):renice i C er:
NAME
getpriority, setpriority - get/set program scheduling priority
SYNOPSIS
#include <sys/time.h>
#include <sys/resource.h>
int getpriority(int which, int who);
int setpriority(int which, int who, int prio);
Bemærkning: programmet skal køre med root rettigheder, hvis prioriteten skal være bedre (mindre end 0 er bedre, større end 0 er værre)
fra
setpriority(2) man siden.
skift af identitet (svarer til su-kommandoen uden at kunne køre et andet program) er i C:
NAME
setuid - set user identity
SYNOPSIS
#include <sys/types.h>
#include <unistd.h>
int setuid(uid_t uid);
fra
setuid(2) man siden
Til dem der er interesseret i at vide det, så skal der også er fork(i en if sætnings test del)-exec*-wait system kaldene bruges for at kunne starte at andet program på Linux/UNIX/*BSD styresystemer.
fork - til at lave en ny proces(=program, der er en kopi af det program det blev startet fra):
NAME
fork - create a new process
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <sys/types.h>
#include <unistd.h>
pid_t
fork(void);
fra
fork(2) man siden
exec* - til at man i en ny proces kan erstatte det program der kører nu med et andet:
NAME
execl, execlp, execle, execv, execvp - execute a file
SYNOPSIS
#include <unistd.h>
extern char **environ;
int execl(const char *path, const char *arg, ...);
int execlp(const char *file, const char *arg, ...);
int execle(const char *path, const char *arg,
..., char * const envp[]);
int execv(const char *path, char *const argv[]);
int execvp(const char *file, char *const argv[]);
DESCRIPTION
The exec() family of functions replaces the current process image with
a new process image. The functions described in this manual page are
front-ends for execve(2). (See the manual page for execve(2) for
further details about the replacement of the current process image.)
....
fra
exec(3) man siden.
wait - bruger vi til at vente på at et program vi har startet bliver færdig - det gør vi for at undgå zombie processer.
NAME
wait, waitpid, waitid - wait for process to change state
SYNOPSIS
#include <sys/types.h>
#include <sys/wait.h>
pid_t wait(int *status);
pid_t waitpid(pid_t pid, int *status, int options);
int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options);
fra
wait(2) man siden
Lidt om zombie processer (og kill -9):
Why can't I kill a process with -9?
One of the early things people learn about Unix is that a "kill -9" is invincible- that a process must die if you send it a KILL (-9). However, that's not entirely true:
* A process can be sleeping in kernel code. Usually that's because of faulty hardware or a badly written driver- or maybe a little of both. A device that isn't set to the interrupt the driver thinks it is can cause this, for example- the driver is waiting for something its never going to get. The process doesn't ignore your signal- it just never gets it.
* A zombie process doesn't react to signals because it's not really a process at all- it's just what's left over after it died. What's supposed to happen is that its parent process was to issue a "wait()" to collect the information about its exit. If the parent doesn't (programming error or just bad programming), you get a zombie. The zombie will go away if its parent dies- it will be "adopted" by init which will do the wait()- so if you see one hanging about, check its parent; if it is init, it will be gone soon, if not the only recourse is to kill the parent..which you may or may not want to do.
* Finally, a process that is being traced (by a debugger, for example) won't react to the KILL either.
citat fra:
http://aplawrence.com/SCOFAQ/FAQ_scotec6cantkill.html
/Lars
Jeg er Software ingeniør (Diplomingeniør) i Informationsteknologi og
indlejede systemer, hvor indlejrede systemer
er computer (microcontroller) + elektronik i for eksempel et TV, en router, en vaskemaskine og den slags
