You are not logged in.
Pages: 1
deleted
Last edited by Misbah (2012-02-14 05:53:41)
Offline
mm I remember seeing a similar message, and later realised I had both added slim as a daemon and used the inittab method so I just got rid of loading it as a daemon and its fine now
ARCH64 | XMonad | Configs | myAURpkgs | ArchWiki Contribs | Screenies
Offline
Either way is fine; just 2 different methods of achieving the same result. Some people prefer the inittab method and consider it 'cleaner'.
As for >& /dev/null, this is merely redirecting the output from the preceding command to the null device. In Unix-like operating systems, /dev/null or 'the null device' is just a file that discards all data written to it (but reports that the write operation succeeded), and provides no data to any process that reads from it (it returns EOF). In Unix programmer jargon, it may also be called the bit bucket or black hole.
The null device is typically used for disposing of unwanted output streams of a process, or as a convenient empty file for input streams. This is usually done by redirection, as in the example you cited.
Offline
Did you change back to init 3 default in inittab when using daemon method?
Also as Misfit said its a preference, but I like inittab method because then I can easily specify boot to init 3 in grub or lilo if X is hosed.
Offline
deleted
Last edited by Misbah (2012-02-14 05:53:25)
Offline
My guess would be that it was caused by the daemon. I had the same problems once when I tried to use entranced. It kept relaunching for some reason--very annoying.
configs... Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
deleted
Last edited by Misbah (2012-02-14 05:53:07)
Offline
The only time I've seen such a message, "'x' respawning too fast: disabled for 5 minutes", was due to my mistake of having slim started both by inittab and as daemon; I switched method but forgot to complete all changes.
Offline
Pages: 1