[chiglug] systemd

[William Giokas]

About 1, I would disagree. An rc file can have any scripting language the
author can rely on to be on the system (zhs, bash, sh, perl, etc.), there's
no standardized options. Does init script x fork the exact same way as y?
They could be in written very differently. When systemd services are looked
at, either at the file or with systemctl show, the options are all listed.

Also, while looking at a shell script may be second nature to users like
us, to newer or less experienced users, and not importantly machines,
systemd services are vastly easier to parse. Certain things can't be
achieved through the options systemd gives you, but then at that point you
can just use an initscript in systemd, if need be.

Bill Giokas
http://kaictl.net/
On Nov 10, 2015 1:15 PM, "Derek Pressnall" <derekp at needcaffeine.net> wrote:

> I really like systemd in general, but there are a few things that gets me:
> 1) It isn't as transparent as rc files
> When there is a problem, you can't just turn on -xv in the bash
> scripts to see what all is going on.  And with the parallel startup
> nature, it is hard to figure out which messages are related to a given
> hang condition on startup.  Of course, there are systemd-specific
> commands that can be use to diagnose issues, but that is an additional
> learning curve (traditionally, there was an easy transition from
> normal Unix admin skills to Linux).
>
> Here's a real-world example that I ran into recently: the system
> (Fedora 22 I believe) hung up in the middle of shutdown, giving me no
> option other than a hard power off.  Apparently, I mounted a Windows
> SMB file share manually, and systemd decided to cut the network off
> before unmounting the share.  So the shutdown hung.  Now maybe I
> should have added a line in /etc/fstab indicating this was a _netdev,
> but I still should be able to temporarily mount a filesystem from the
> command line.
>
> 2) Could systemd still do its magic if it wasn't PID 1?  That is, keep
> a very simple traditional init, which then launches systemd that would
> then own the bulk of the other services.  This would allow peace an
> harmony between the old and new way of doing things.  But then again,
> I imagine that systemd wouldn't be as useful if there were other
> processes running outside of it.
>
> Now, something I'd like to see added (if it can be done with the
> existing systemd framework):  Could systemd intercept a console key
> combination that brings up a (password-protected) rescue environment?
> That way if there is a problem on startup or shutdown, this can be
> used to at least help diagnose the issue.  The environment could be a
> command shell with all the busybox commands pre-linked into it (so
> that it wouldn't even require a mounted root image).
>
> On Mon, Nov 9, 2015 at 9:01 AM, sten <me at sud0.com> wrote:
> > Hey,
> >
> > So I'm trying to put together a presentation about systemd for people who
> > have decided they have some sort of problem with systemd. I'd love for
> it to
> > be conversational styled - me and someone (or someones) who wants to
> talk in
> > front of people in favor of sysvinit or a different alternative.
> >
> > I talked to a couple folks 2 meetings ago, but I may have been overly
> > confrontational about it, and I really want to hear what objections still
> > remain.
> >
> > Drop me a note on- or off-list, let's see if we can come up with
> something
> > together.
> >
> > -sten
> >
> >
> > _______________________________________________
> > discuss mailing list
> > discuss at lists.chicagolug.org
> > https://lists.chicagolug.org/mailman/listinfo/discuss
> >
>
> _______________________________________________
> discuss mailing list
> discuss at lists.chicagolug.org
> https://lists.chicagolug.org/mailman/listinfo/discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chicagolug.org/pipermail/discuss/attachments/20151110/f6d3491b/attachment-0002.html>