| View previous topic :: View next topic |
| Author |
Message |
smlgbl
Guru
Joined: 10 Feb 2005
Posts: 305
|
 Posted: Wed Nov 22, 2006 10:52 pm Post subject: |
 |
|
| rmh3093 wrote: | | mine does that every once and a while now also |
But mine does it all the time now...back to sysVinit, I guess... 
_________________
samuel.
'Do not let one girding on boast about himself like one unfastening' |
|
| Back to top |
|
 |
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Wed Nov 22, 2006 10:58 pm Post subject: |
|
|
what happens if you remove xdm from any mode and start your wm manually? can you get in?
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu Nov 23, 2006 1:27 am Post subject: |
|
|
I think einit (the daemons and shell mods) could really benefit from a remove-pid attribute which automatically deletes the specified pid file... such that if remove-pid=1 for a certain daemon or shell mod it would look for the pid variable associated id of the service
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Thu Nov 23, 2006 8:25 am Post subject: |
|
|
uh, haven't changed anything that wicked actually. some functions, but those weren't being used by anyone yet?
what about the 0.12.1 release, i think i haven't changed anything major since then?
some api changes, yes, but the necessary functions for a reboot should definitely not be called no matter what
edit: could you post your definitions for the default mode? (both from einit.xml and local.xml)?
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
smlgbl
Guru
Joined: 10 Feb 2005
Posts: 305
|
| Posted: Thu Nov 23, 2006 8:46 am Post subject: |
|
|
Well, wierd as it is, I reverted to 0.12.1 yesterday as well, but it still did it. So back to cvs. Then I was tired and went to bed.  Now, this morning everything seems to be fine again. Still, my config is on my page.
Otherwise: HÄÄÄÄÄÄÄÄÄ?????
EDIT: I've got a theory, why the unmounting doesn't work properly. First of all, I've got more things mounted on /mnt/win, /mnt/silke, ..., aso. Secondly, there are still kernel modules running, that don't get wiped. I don't know, if that might matter, but I wanted to mention it.
_________________
samuel.
'Do not let one girding on boast about himself like one unfastening'
Last edited by smlgbl on Thu Nov 23, 2006 5:11 pm; edited 1 time in total |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu Nov 23, 2006 2:03 pm Post subject: |
|
|
yeah rebooting used to be really smooth, now It seems like my computer never boots
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu Nov 23, 2006 2:24 pm Post subject: |
|
|
| cupsd: | <daemon id="daemon-cupsd"
name="cupsd - common unix printing system daemon"
provides="cupsd"
requires="mount/critical:net-lo"
command="cupsd -f"
restart="yes" />
|
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Thu Nov 23, 2006 5:58 pm Post subject: |
|
|
well, my theory was that processes were still having their root below certain mountpoints... i've created a small new module that should be able to find all processes that have their cwd below certain directories, so now if i just extend that to be able to spot all descendants of a process so i can kill the ttys and make einit-tty and einit-mount use these functions... 
i'd think the modules would likely refuse to be removed if there's still filesystems that use this somewhere... also i think gentoo's sysv scripts don't unload all modules?
these sporadic reboots are very weird actually... we've had those for quite a while already, haven't we?
about these reboots, does the computer simply reboot "just like that", or do you see any indication of einit shutting down and rebooting?
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu Nov 23, 2006 6:04 pm Post subject: |
|
|
| mdeininger wrote: | well, my theory was that processes were still having their root below certain mountpoints... i've created a small new module that should be able to find all processes that have their cwd below certain directories, so now if i just extend that to be able to spot all descendants of a process so i can kill the ttys and make einit-tty and einit-mount use these functions...
i'd think the modules would likely refuse to be removed if there's still filesystems that use this somewhere... also i think gentoo's sysv scripts don't unload all modules?
these sporadic reboots are very weird actually... we've had those for quite a while already, haven't we?
about these reboots, does the computer simply reboot "just like that", or do you see any indication of einit shutting down and rebooting? |
what about killing daemons that have control of modules... for example, i have a daemon that controls the radio on my wireless card, the daemon needs to be started after the module is loaded and it must be killed before the module is removed.... is there a way we can define pre/post enable and pre/post disable functions, or at least define shutdown deps?
EDIT: my wireless card needs to be shutdown properly or else the daemon dosent start the interface properly on reboot
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Thu Nov 23, 2006 6:21 pm Post subject: |
|
|
you mean, if the daemon is below a certain mountpoint that needs to be disabled?
usually your module shouldn't have its cwd anywhere that could cause trouble. most of them should have / or maybe their chroot-jail. also, whenever you write a module like that, you'll probably specify what mountpoints need to be available for the module to load successfully, right? well, einit will only try to unmount the specified set of mountpoints after all modules that did depend on it have been successfully disabled, so if that control daemon is still alive after that below a mountpoint that needs to be unmounted, something is wrong with the daemon, isn't it? 
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu Nov 23, 2006 8:03 pm Post subject: |
|
|
| mdeininger wrote: | you mean, if the daemon is below a certain mountpoint that needs to be disabled?
usually your module shouldn't have its cwd anywhere that could cause trouble. most of them should have / or maybe their chroot-jail. also, whenever you write a module like that, you'll probably specify what mountpoints need to be available for the module to load successfully, right? well, einit will only try to unmount the specified set of mountpoints after all modules that did depend on it have been successfully disabled, so if that control daemon is still alive after that below a mountpoint that needs to be unmounted, something is wrong with the daemon, isn't it? |
no sorry this has nothing to do with mounts... im just curious as to the order einit kills things off on a shutdown or reboot because i need my wireless card to shutdown a particular way (first kill the RF daemon, then remove the module) most of the time I try and reboot everything associated with the network is still up
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Thu Nov 23, 2006 8:21 pm Post subject: |
|
|
| rmh3093 wrote: | | no sorry this has nothing to do with mounts... im just curious as to the order einit kills things off on a shutdown or reboot because i need my wireless card to shutdown a particular way (first kill the RF daemon, then remove the module) most of the time I try and reboot everything associated with the network is still up |
oh, that was what i thought at first, then i thought you had objections about the mount/killing part... 
okay, it basically works like this: those requirements you set for your modules determine the order. on shutdown, the module-logics code will collect all modules that are enabled and save a link to their headers and their service ids in a set of things to be unloaded. then in the next step, when the actual mode-switch is applied, it'll basically fork of processes to disable everything in there. since the core will refuse to disable anything that is required, it'll recursively disable things that depended on whatever it's trying to disable. this way, einit will basically do the same dependency checks as on startup.
as for the actual disabling of the modules: basically all modules export a function to be called. with <daemon /> and <shell /> modules that function is provided by their respective module loaders. with a <shell /> module, the function will simply pass the command in disable="" to "/bin/sh -c" and the return value depends on the exit-code of the shell (usually the exit code of the last command execute).
for <daemon /> modules, enabling/disabling works like this:
| enabling wrote: | * first: execute whatever is in prepare="", if it exists
* fork and execute the command in command="" (by passing it to /bin/sh -c) |
| disabling wrote: | * note down that the pid will die soon (so it won't be restarted)
* send a SIGTERM to the pid of whatever we forked to earlier to start the daemon
* wait for the process to die...
* execute whatever command is in cleanup="" |
if the daemon dies too often/too fast, then einit will stop restarting it and execute the command in cleanup="".
so, as for your daemon/module, the easy way would be:
| Code: | <daemon id="daemon-wlan" name="WLAN"
prepare="modprobe whatever"
command="/path/to/your/daemon"
cleanup="rmmod whatever" /> |
well, either that or create two modules: one for the module, one for the daemon, and make the daemon require the module-loading module. then on shutdown, the module won't be unloaded until the daemon is dead, but it will definitely be flagged as "to be disabled", so einit will try to disable it, disable the daemon first (since the module-loading module is being used by the daemon, as you specified that), then only run the disable command for your module-loader when the daemon goes down...
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu Nov 23, 2006 8:32 pm Post subject: |
|
|
thats exactly what I wanted....
now, can i do something like prepare="einit-control disable kern-ethernet" ??
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Thu Nov 23, 2006 8:37 pm Post subject: |
|
|
i've no idea what would happen if you did that
am i interpreting that right that you wish to disable the module upon starting the daemon?
(EDIT: it should be "erc kern-ethernet disable" or "einit-control rc kern-ethernet disable", if anything... still, it'll probably do nothing since it'll only queue that status change to be performed after whatever einit is doing at the time it's enabling this module...)
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu Nov 23, 2006 9:15 pm Post subject: |
|
|
| mdeininger wrote: | i've no idea what would happen if you did that
am i interpreting that right that you wish to disable the module upon starting the daemon?
(EDIT: it should be "erc kern-ethernet disable" or "einit-control rc kern-ethernet disable", if anything... still, it'll probably do nothing since it'll only queue that status change to be performed after whatever einit is doing at the time it's enabling this module...) |
i can not figure out how to kill this damn daemon!!!!
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Thu Nov 23, 2006 9:17 pm Post subject: |
|
|
| rmh3093 wrote: | | mdeininger wrote: | i've no idea what would happen if you did that
am i interpreting that right that you wish to disable the module upon starting the daemon?
(EDIT: it should be "erc kern-ethernet disable" or "einit-control rc kern-ethernet disable", if anything... still, it'll probably do nothing since it'll only queue that status change to be performed after whatever einit is doing at the time it's enabling this module...) |
i can not figure out how to kill this damn daemon!!!! |
killall?
why don't you show me your current definitions so i can try to work something out?
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
pteppic
l33t
Joined: 28 Nov 2005
Posts: 781
|
| Posted: Thu Nov 23, 2006 10:33 pm Post subject: |
|
|
Is there a simple way to tell if something should be implemented as a daemon or as a shell (other than not working as a daemon).
Also, is there a central place to submit/get critique on module scripts, or should I post them here (or a new thread maybe?). |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu Nov 23, 2006 11:56 pm Post subject: |
|
|
just post them as eInit needs all the modules it can get.... magnus will include them at some point
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Fri Nov 24, 2006 11:04 am Post subject: |
|
|
well, you can either post them here or on the wiki, if they sound non-experimental and it's OK with you, i'd put them in the main einit.xml on CVS.
you can start a daemon using a shell-script and vice versa, it all depends on what you want to do. if you simply wish to enter some shell-commands to execute, use the shell-type, if you want to start something that einit should actually keep alive, then use daemon.
bad thing about keeping programs alive is that you need to be able to tell the program not to fork, but most daemons do so by default
EDIT: rmh, did you work something out about your misbehaving daemon yet? you could still write me a pm with the data, because i'm still wondring why not to use the daemon prepare/command/cleanup way
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
pteppic
l33t
Joined: 28 Nov 2005
Posts: 781
|
| Posted: Fri Nov 24, 2006 3:22 pm Post subject: |
|
|
| mdeininger wrote: | | well, you can either post them here or on the wiki |
In that case I'll find somewhere on the wiki, if I post them here they will be buried in a few weeks, and may be improved without people noticing, at least if they are on the wiki they can be edited in the same place.
Thanks. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Fri Nov 24, 2006 3:44 pm Post subject: |
|
|
| mdeininger wrote: | well, you can either post them here or on the wiki, if they sound non-experimental and it's OK with you, i'd put them in the main einit.xml on CVS.
you can start a daemon using a shell-script and vice versa, it all depends on what you want to do. if you simply wish to enter some shell-commands to execute, use the shell-type, if you want to start something that einit should actually keep alive, then use daemon.
bad thing about keeping programs alive is that you need to be able to tell the program not to fork, but most daemons do so by default
EDIT: rmh, did you work something out about your misbehaving daemon yet? you could still write me a pm with the data, because i'm still wondring why not to use the daemon prepare/command/cleanup way |
well actually, it seems most of the problems I have been is selecting the right dependencies to get it to boot and then not hang on reboot
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
pteppic
l33t
Joined: 28 Nov 2005
Posts: 781
|
| Posted: Fri Nov 24, 2006 4:07 pm Post subject: |
|
|
I put the ones I wrote yesterday in the wiki, if someone closer to the project wants to move the link/format around feel free.
I really like this piece of software, and seeing the poor state of the wiki (no offence, more important things to do, I know) , I'll go through this thread when I get time and port peoples xml over to it, if no one has any objections? |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Fri Nov 24, 2006 4:52 pm Post subject: |
|
|
great, thank you
you're right, the wiki isn't in much of a shape. i suppose that's in part due to the flakeyness of my ISP which can make editing pages a PITA at times. then again, i see the documentation getting outdated rather swiftly at the same time :/
rmh: there's no actual need to make your module require the network group you know, you could also load the kernel module for your specific card in your module... couldn't that solve your problem?
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Fri Nov 24, 2006 5:05 pm Post subject: |
|
|
| mdeininger wrote: | great, thank you
you're right, the wiki isn't in much of a shape. i suppose that's in part due to the flakeyness of my ISP which can make editing pages a PITA at times. then again, i see the documentation getting outdated rather swiftly at the same time :/
rmh: there's no actual need to make your module require the network group you know, you could also load the kernel module for your specific card in your module... couldn't that solve your problem? |
that is how I solved the issue (at least killing the daemon and removing the module)....
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Fri Nov 24, 2006 5:11 pm Post subject: |
|
|
| rmh3093 wrote: | | that is how I solved the issue (at least killing the daemon and removing the module).... |
ah, sorry, i thought you still had issues with getting it to work at all 
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
