On 5/11/2011 10:44 AM, Chow Loong Jin wrote:
On the other hand, you can't possibly hope to convince anyone that a persistent
screen session requiring a specialized init task is a feature, not a bug.
It doesn't require a specialized anything.
A persistent ANYTHING when transitioning to runlevel s is a bug. As for
stopping gdm, it comes down to what does that action mean? I've always
thought of it has meaning stop gdm and everything that has resulted from
it. If you don't want that task to have that meaning, then I believe
systemd leaves you the option of configuring it not to, but with upstart
you have no choice: it CAN NOT make sure everything resulting from gdm
has actually been stopped.
Let's also not forget old SysV-style /etc/init.d/* scripts that may have been
started from a graphical terminal, which will inevitably go down with
gdm/$display_manager based on what you're proposing. Or are we supposed to break
every init script not ported to systemd until the transition to systemd is
complete? This would have some serious repercussions on the syncability of
packages with init scripts from Debian.
In other words, any daemons that you manually start instead of using
initctl. I actually have always felt that the whole rc script system is
fundamentally broken and the jobs should be listed in inittab so that
init knows about them and can restart them if needed, rather than have
some script fork off a process that init has no idea exists.
They also would not be "broken" just because if you happen to run it to
manually start a daemon, and if you stop gdm, and if systemd is
configured to fully stop the whole process tree, then that daemon would
also be stopped.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
