systemd now appears to be only possible init system in testing

Forward this to the debian CTTE, please!

Post by Julian Gilbey
I just tried updating testing on my system. I currently use
sysvinit-core (reasons below), but aptitude is telling me that I
should remove this in favour of systemd-sysv. Hmm, why is that?
Well, because the new version of libpam-systemd, 208-6, now depends on
systemd-sysv rather than systemd-sysv | systemd-shim. OK, so I'll
remove libpam-systemd. Ooops - that looks pretty disastrous, as so
much depends on it, so that's not an option: gdm3, gnome-bluetooth,
network-manager, policykit-1, udisks2.
So I would presume that for many or most Debian systems, systemd is
now required, and no other /sbin/init providers will work. I'm
unclear whether this was a deliberate policy decision or an unintended
consequence of various package requirements.
For me, this is a killer, as I still do not know how to solve the
problem I asked a while back on debian-user
(https://lists.debian.org/debian-user/2014/04/msg01286.html): in
summary, I need to unlock an encrypted filesystem during boot time by
asking for a password to feed into encfs. But I cannot figure out how
to do this under systemd.
Answers to this question would also be much appreciated!
Julian

Julian Gilbey

2014-07-22 23:08:04 UTC

Post by Svante Signell
Forward this to the debian CTTE, please!

Thanks for the suggestion, Svante! I've just reread
https://www.debian.org/devel/tech-ctte and it does not yet seem
appropriate for the CTTE; there has not yet been any discussion with
the relevant package maintainers.

A bit more searching (reading the relevant changelogs) has shown that
bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752939 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754984 contain a lot
more information about this issue.

It seems that once cgmanager 0.27 is allowed into unstable from NEW, a
new version of systemd-shim will be able to be uploaded, which will
allow libpam-systemd to coexist with sysvinit once again.

It's just a shame that various migrations to testing were allowed
before this had been resolved :-(

Anyway, I would still love to know how to write a systemd script which
pauses to accept input from the keyboard before continuing.

Julian

Post by Svante Signell

Charles Plessy

2014-07-22 23:34:45 UTC

Post by Julian Gilbey
Anyway, I would still love to know how to write a systemd script which
pauses to accept input from the keyboard before continuing.

Hi Julian,

I suggest to ask this question on pkg-systemd-***@lists.alioth.debian.org
or even on systemd-***@lists.freedesktop.org. Pepole there are supportive and
may be able to help you to find the way to boot your encrypted filesystem while
using systemd.

On debian-devel unfortunately, there are too many people who will actively
repel any attempt of solving your problem (a few pepole are enough to destroy
the productivity of a mailing list).

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@falafel.plessy.net

Ben Hutchings

2014-07-23 01:02:04 UTC

Post by Julian Gilbey

Post by Svante Signell
Forward this to the debian CTTE, please!

Thanks for the suggestion, Svante! I've just reread
https://www.debian.org/devel/tech-ctte and it does not yet seem
appropriate for the CTTE; there has not yet been any discussion with
the relevant package maintainers.
A bit more searching (reading the relevant changelogs) has shown that
bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752939 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754984 contain a lot
more information about this issue.
It seems that once cgmanager 0.27 is allowed into unstable from NEW, a
new version of systemd-shim will be able to be uploaded, which will
allow libpam-systemd to coexist with sysvinit once again.
It's just a shame that various migrations to testing were allowed
before this had been resolved :-(
Anyway, I would still love to know how to write a systemd script which
pauses to accept input from the keyboard before continuing.

I believe you're supposed to do that through plymouth (which does not
imply a graphical boot splash; it has a text mode as well).

Ben.

--
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer

Norbert Preining

2014-07-22 22:53:05 UTC

Hi Julian,

long time no see!

[ IMPORTANT - COC DISCLAIMER - IMPORTANT - PLEASE READ BEFORE CONTINUING ]
This email is the personal opinion of its author.
As we are not allowed to criticize due to the newly installed
Code of Conduct, you are required to pre- or postfix *every* sentence
in the following email with one of the following fragments:
. I thing it might be an option to say that ....
. I could reach the opinion that under certain circumstances ...
. In my all too humble opinion, which is not important, ...
Failure to do the above will result in wrong interpretation of the
following email, so stop reading here if you are not ready to do that.
[ COC DISCLAIMER ENDS HERE ]

[ JOKE DISCLAIMER START ]
If you are without humour - stop reading here!
[ JOKE DISCLAIMER END ]

Post by Julian Gilbey
much depends on it, so that's not an option: gdm3, gnome-bluetooth,
network-manager, policykit-1, udisks2.

Yes, if you use *anything* slightly gnome related, you are hosed
and need to install systemd.

You need to get rid of gdm3, gnome-bluetooth, and network-manager,
then it should be possible to get a system without systemd.
If you want one of these ... well, then the systemd mafia got you!

That is Debian, as long nobody steps forward and stops this.

Post by Julian Gilbey
unclear whether this was a deliberate policy decision or an unintended

Deliberate. Since systemd* 208, systemd-shim is "said to be not compatible"
anymore. Well, here we go with freedom.

Post by Julian Gilbey
summary, I need to unlock an encrypted filesystem during boot time by
asking for a password to feed into encfs. But I cannot figure out how
to do this under systemd.

Everything can be done in systemd, since it is Turing complete.
The only problem is that nobody knows how to, it is not predicatable
what will actually happen (formatted hard disk, crashed kernel, etc).

In your case I *strongly* recommend to remove nm, gdm3 and by this
get rid of systemd, too.

Post by Julian Gilbey
Answers to this question would also be much appreciated!

There are thousands of emails here, all with the same effect:

We have commit rights, so go away and shut up!

or alternatively

We are systemd, and we are now the only init system in Debian,
so go away and shut up.

or again alternatively

One init to rule them all, to bind them, and throw them into
darkness!

Fortunately, I don't use encrypted disks or anything fancy, so I am
stupid dummy user that has no special requirements. So I am free to
use systemd, because this is the target audience!

If you would fall into the same category, you could be happy, too, but
alas, ... you are a power user and thus hosed.

Norbert

[ END OF DISCLAIMER GOVERNED TEXT ]

------------------------------------------------------------------------
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
------------------------------------------------------------------------

Christian Hofstaedtler

2014-07-22 23:26:28 UTC

Post by Norbert Preining
[ IMPORTANT - COC DISCLAIMER - IMPORTANT - PLEASE READ BEFORE CONTINUING ]
This email is the personal opinion of its author.
As we are not allowed to criticize due to the newly installed
Code of Conduct, you are required to pre- or postfix *every* sentence
. I thing it might be an option to say that ....
. I could reach the opinion that under certain circumstances ...
. In my all too humble opinion, which is not important, ...
Failure to do the above will result in wrong interpretation of the
following email, so stop reading here if you are not ready to do that.
[ COC DISCLAIMER ENDS HERE ]

How does "write a disclaimer in the hope of justifying possible
violations of rules instead of doing something productive" fit into
anybody's applied business logic?

C.

Ben Finney

2014-07-22 23:46:12 UTC

Post by Norbert Preining
[ IMPORTANT - COC DISCLAIMER - IMPORTANT - PLEASE READ BEFORE
CONTINUING ]

Writing a disclaimer doesn't exempt you from the Code of conduct in
Debian forums. Please don't violate it again.
--
\ “It's up to the masses to distribute [music] however they want |
`\ … The laws don't matter at that point. People sharing music in |
_o__) their bedrooms is the new radio.” —Neil Young, 2008-05-06 |
Ben Finney

--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@benfinney.id.au

Thomas Goirand

2014-07-23 07:32:00 UTC

Post by Ben Finney
Writing a disclaimer doesn't exempt you from the Code of conduct in
Debian forums. Please don't violate it again.

If the CoC makes it impossible for Norbert to express himself in the way
he just did, then the CoC is bad and should be repelled.

I'm getting really tired of the internet police and thoughts control...

Thomas

Matthias Urlichs

2014-07-23 08:07:29 UTC

Hi,

Post by Thomas Goirand
If the CoC makes it impossible for Norbert to express himself in the way
he just did, then the CoC is bad and should be repelled.

*repealed.

I disagree. Insinuating that the systemd proponents' goal is

Post by Thomas Goirand

"One init to rule them all, to bind them, and throw them into darkness!"

is not a contribution to this mailing list that's suitable for furthering
reasoned discourse. To put it mildly. Adding a disclaimer doesn't help,
frankly.

Post by Thomas Goirand
I'm getting really tired of the internet police and thoughts control...

Well, some other people are way past getting tired of people who jump in
with an anti-systemd rant every time somebody has a legitimate problem
with (part of) it, so I guess we're even. :-P

In any case, requesting reasoned discourse instead of rants on this list
is not "thought control". You're free to think whatever you want about
systemd. You're also free to express these thoughts in any way, shape or
form you want – but if you need to do it in a way that is detrimental to
this list, please do it someplace else.

--
-- Matthias Urlichs
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@smurf.noris.de

Sune Vuorela

2014-07-23 08:20:43 UTC

Post by Thomas Goirand
If the CoC makes it impossible for Norbert to express himself in the way
he just did, then the CoC is bad and should be repelled.

If the CoC helps ensure that Norbert doesn't again say "I don't give a
shit about other people's work" - and you doesn't again say "Let's have
someone run over specific developers with a bus", then the CoC is good.

/Sune

Sune Vuorela

2014-07-23 08:42:17 UTC

Post by Sune Vuorela
and you doesn't again say "Let's have
someone run over specific developers with a bus", then the CoC is good.

Dear Thomas

I sincerely apologize for the above line. Somehow my internal memory
mixed up one T... G... with another.

I'm really sorry.

/Sune

Thomas Goirand

2014-07-24 06:46:56 UTC

Post by Sune Vuorela

Post by Sune Vuorela
and you doesn't again say "Let's have
someone run over specific developers with a bus", then the CoC is good.

Dear Thomas
I sincerely apologize for the above line. Somehow my internal memory
mixed up one T... G... with another.

LOL ! I'm not that person you're referring to indeed (if we're thinking
about the same one). I hope my style is a bit less aggressive than this.

I've been trying hard to make my posts more readable over the last
years, I hope it shows. And if it doesn't, please let me know privately
why so I can correct myself, as mistakes can always happen.

Thomas

Stuart Prescott

2014-07-23 14:28:12 UTC

Hi Norbert,

Please remember these arguments you have been making next time you make what
you believe are perfectly justified changes to the texlive packaging by
(once again) introducing new and incompatible versions of sty files or
moving files between packages.

I'm sure the texlive maintainers feel perfectly justified in breaking
existing setups and causing packages to FTBFS by doing this. I'm sure you
can explain to me that it's all much better for the changes, even though it
looks like it only makes work for me. I understand that to a large extent
your hands are tied because you need to track upstream releases and you
can't hold a style file at an ancient version forever just to make sure that
nothing gets broken.

Because I trust the texlive maintainers to be fundamentally doing the right
things for Debian, I don't reassign all the bugs you cause to the texlive
packages because they were the ones that broke their reverse-dependencies.
Rather, I spend the time to adapt to the new way. Similarly, I don't rant on
mailing lists about how the world is going to end because of this breakage.
I don't make insinuations about the competence of the texlive maintainers
when I don't understand why they have done something. I don't belittle your
work. I don't run around complaining that your approach to texlive is a
giant conspiracy.

The same is true for a package like systemd-shim which would permit you to
use the packages you talked about without running systemd. systemd-shim has
to adapt to the changing landscape around it and it is the responsibility of
its authors (NOT the systemd maintainers) to have it ready and functioning.
What's more, I believe that work is well advanced and you'll find more
information about that in this thread.

A little empathy for fellow developers, a little time looking in the mirror
and some effort to see things from other perspectives would go a long way
and be greatly appreciated.

Stuart

--
Stuart Prescott http://www.nanonanonano.net/ ***@nanonanonano.net
Debian Developer http://www.debian.org/ ***@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Juliusz Chroboczek

2014-07-23 15:09:55 UTC

Post by Stuart Prescott
I'm sure the texlive maintainers feel perfectly justified in breaking
existing setups and causing packages to FTBFS by doing this.

I don't think the comparison between texlive and systemd is quite fair.
Texlive updates don't break users' systems, they just make some packages
temporarily un-upgradeable. And even if they did break, they wouldn't
break the systems of troff users.

To some of us, this transition is starting to feel like a rather unsubtle
attempt to force systemd down everyone's throat, whether we want it or
not. I still believe that this is just bad coordination and bad communi-
cation on the part of the systemd packagers, and sincerely hope that this
is not a coordinated attack on non-systemd installations.

-- Juliusz

Matthias Urlichs

2014-07-23 16:30:48 UTC

Hi,

Post by Juliusz Chroboczek
I don't think the comparison between texlive and systemd is quite fair.

Any comparison will have its "apples vs. potatoes" aspects.
That doesn't invalidate the comparable parts.

Post by Juliusz Chroboczek
I still believe that this is just bad coordination and bad communi-
cation on the part of the systemd packagers

Steve (Langasek) already stated that he will not belabor this point,
and he's the systemd-shim maintainer. He is thus in a far better position
to assign blame / sinister motives / unwillingness to cooperate
to the systemd people.

Or not.

--
-- Matthias Urlichs

Holger Levsen

2014-07-22 23:26:47 UTC

Hi,

(as this thread has already attracted two "interesting replies", I'll try
again to convey the message which has not been heard yet... I don't have high
hopes this thread won't become a flamefest, but I want to at least try to kill
the flames before they explode...)

(And if you know systemd, please scroll down and help Julian with his actual
question...)

Because all modern desktops now need systemd so all features work. blame
upstream^w^wsend patches to upstream and Debian will have those...

Really, get over it or do something. Ranting on -devel will not change
anything.

And this is actually pretty old news too: see
http://layer-acht.org/thinking/blog/2014-06-03-systemd-mostly-harmless/

Thank you.

Post by Julian Gilbey
So I would presume that for many or most Debian systems, systemd is
now required

s#most Debian systems#most Debian desktop systems#

Post by Julian Gilbey
For me, this is a killer, as I still do not know how to solve the
problem I asked a while back on debian-user
(https://lists.debian.org/debian-user/2014/04/msg01286.html): in
summary, I need to unlock an encrypted filesystem during boot time by
asking for a password to feed into encfs. But I cannot figure out how
to do this under systemd.
Answers to this question would also be much appreciated!

I hope someone will be able to help Julian with this question...

cheers,
Holger

Russ Allbery

2014-07-22 23:58:16 UTC

Post by Holger Levsen

I hope someone will be able to help Julian with this question...

This is just speculation, and I've not tried this, but my first thought in
reading this message is that the --no-tty part is a mistake. The
documentation of that option says:

When run with no TTY or with --no-tty it will query the password
system-wide and allow active users to respond via several agents. The
latter is only available to privileged processes.

However, you're doing this during boot, so there *are* no active users,
since the system hasn't come up far enough to let anyone log in yet. So
it makes sense that you don't get a prompt.

I suspect you instead need to run systemd-ask-password with a tty. Take a
look at systemd.exec(5) at the TTY* options for the systemd unit file. I
suspect you need to write a unit file corresponding to your init script
that runs systemd-ask-password and uses TTYPath=/dev/tty1.

--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>

Juliusz Chroboczek

2014-07-23 15:11:34 UTC

Post by Russ Allbery
However, you're doing this during boot, so there *are* no active users,
since the system hasn't come up far enough to let anyone log in yet. So
it makes sense that you don't get a prompt.

Does that mean that the new pid 1 expects users to be logged in before it
starts the system?

-- Juliusz

Russ Allbery

2014-07-23 17:21:31 UTC

Post by Juliusz Chroboczek

Does that mean that the new pid 1 expects users to be logged in before it
starts the system?

No, of course not.

The tool that you're using isn't only for use during early boot, and
you're using it in a way that is incorrect for use during early boot. The
solution is to use the tool correctly.

--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>

Steve Langasek

2014-07-23 01:05:06 UTC

Post by Holger Levsen

Because all modern desktops now need systemd so all features work. blame
upstream^w^wsend patches to upstream and Debian will have those...

What they need is logind. Saying "needs systemd" for things that need
logind is as hopelessly confusing as if you were to say it for things that
need udev.

logind itself currently needs systemd as PID 1, because systemd 208 was
uploaded to unstable (and has migrated to testing) before systemd-shim has
been updated for compatibility.

I have already opined that I think this was a bad idea and will not belabor
the point.

Post by Holger Levsen
Really, get over it or do something. Ranting on -devel will not change
anything.

There was nothing in Julian's message which was a rant, so I don't think
this response is called for. He *was* doing something about a systemd
integration problem that was a blocker for him - he was asking for help.

If we have to go through this same sequence of messages every time someone
asks on debian-devel for help with a systemd issue, it's going to be a long
release cycle.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Holger Levsen

2014-07-23 01:58:32 UTC

Hi Steve,

thanks for the technical details, much appreciated.

Post by Steve Langasek
There was nothing in Julian's message which was a rant, so I don't think
this response is called for.

Well, the subject (and also the body) conveyed the wrong message, that systemd
is mandatory in Debian now. Which - as you also said - is wrong, at least for
two reasons: a.) it's logind, not systemd and b.) only desktops are affected.

And, even though the rest of Julians message was as you described, it
attracted two quite flamatory replies at first...

Post by Steve Langasek
He *was* doing something about a systemd
integration problem that was a blocker for him - he was asking for help.
If we have to go through this same sequence of messages every time someone
asks on debian-devel for help with a systemd issue, it's going to be a long
release cycle.

I totally agree with these parts - and while I do think this thread startly
badly I also think it has become a much nicer one by now. Hopefully this is
more like how systemd threads will be in future too ;)

cheers,
Holger

Adam Borowski

2014-07-23 02:35:48 UTC

Post by Holger Levsen
Well, the subject (and also the body) conveyed the wrong message, that systemd
is mandatory in Debian now. Which - as you also said - is wrong, at least for
two reasons: a.) it's logind, not systemd and b.) only desktops are affected.

apt-get install logind
E: Unable to locate package logind

If logind was detachable from systemd, it would be in a separate package.

For now, just use the last working version of policykit (0.105-4).

--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.

Russ Allbery

2014-07-23 02:54:10 UTC

Post by Adam Borowski

Post by Holger Levsen
Well, the subject (and also the body) conveyed the wrong message, that
systemd is mandatory in Debian now. Which - as you also said - is
wrong, at least for two reasons: a.) it's logind, not systemd and b.)
only desktops are affected.

apt-get install logind
E: Unable to locate package logind
If logind was detachable from systemd, it would be in a separate package.

logind is also not mandatory in Debian now. It's just required, upstream,
by all the major desktop environments.

I think one point Holger was making is that *desktop environments* are not
mandatory in Debian. I have lots of Debian systems, including my desktop,
that don't run any desktop environment at all.

--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>

Vincent Lefevre

2014-07-23 22:46:56 UTC

Post by Russ Allbery
logind is also not mandatory in Debian now. It's just required, upstream,
by all the major desktop environments.

Not just by all the major desktop environments. It is also needed
by hplip via dependencies[*], which is quite surprising for a
"HP Linux Printing and Imaging System".

[*] hplip -> policykit-1 -> libpam-systemd -> systemd

Or is there any abuse of a dependency here?
--
Vincent Lefèvre <***@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@xvii.vinc17.org

Russ Allbery

2014-07-23 23:12:26 UTC

Post by Russ Allbery
logind is also not mandatory in Debian now. It's just required,
upstream, by all the major desktop environments.

Someone with more detailed desktop knowledge should read this over and
correct it as necessary. This is just my understanding of what's going
on, and I don't work with the software in question and could be wrong in
some details.

There is a general class of problems around "let the user on console do
<thing>" that were originally controlled via UNIX groups. The problem
with doing this via UNIX groups is that either you need complicated PAM
machinery to add supplemental groups based on whether the user is on
console, or you have to change the security model to "users who are
allowed to use the console but may not be on console at this time," which
poses other problems.

PolicyKit provided an alternative way of handling those problems, and I
suspect that's why HPLIP depended on PolicyKit. It allowed a more direct
expression of rules like "only users on console can do this."

However, PolicyKit has basically been orphaned upstream, replaced by the
rewritten polkit, and I believe polkit depends on logind to provide core
functionality around knowing what users are on console. So anything that
had switched from something group-based for handling this problem to
PolicyKit has probably moved or is moving to polkit, which relies on
facilities currently only provided by logind.

--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>

Josselin Mouette

2014-07-26 15:20:24 UTC

Post by Russ Allbery
Someone with more detailed desktop knowledge should read this over and
correct it as necessary. This is just my understanding of what's going
on, and I don't work with the software in question and could be wrong in
some details.
However, PolicyKit has basically been orphaned upstream, replaced by the
rewritten polkit, and I believe polkit depends on logind to provide core
functionality around knowing what users are on console.

polkit = PolicyKit
It’s just that PolicyKit used to rely on ConsoleKit to obtain the
information about who is logged on the system. Now that ConsoleKit is
orphaned, the only available information is provided by systemd-logind.
--
.''`. Josselin Mouette
: :' :
`. `'
`-

--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@tomoyo

Christian Hofstaedtler

2014-07-22 23:12:33 UTC

Can't directly help you with this, but the manual page text for
`--no-tty` reads as if it would do the opposite of what you actually
want to do.

C.

--
,''`. Christian Hofstaedtler <***@debian.org>
: :' : Debian Developer
`. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03
`-

Steve Langasek

2014-07-22 23:09:48 UTC

See bug #752939, which is currently blocked on cgmanager, which was in the
NEW queue but for some reason seems to have been rejected rather than
accepted.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Marco d'Itri

2014-07-22 23:21:06 UTC

Post by Julian Gilbey
So I would presume that for many or most Debian systems, systemd is
now required, and no other /sbin/init providers will work. I'm
unclear whether this was a deliberate policy decision or an unintended
consequence of various package requirements.

It is a consequence of systemd-shim not being ready at the time systemd
was last updated in unstable. I understand that now it is, but it still
waiting for NEW processing of one of its dependencies.
If you care so much then maybe you could help the maintainers.

--
ciao,
Marco

Vincent Lefevre

2014-07-22 23:24:53 UTC

As you can see with this dependency, you just need to install
systemd-shim. No need to install systemd-sysv!

The default (systemd-sysv) was just a poor choice from aptitude.
--
Vincent Lefèvre <***@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@xvii.vinc17.org

Vincent Lefevre

2014-07-22 23:39:57 UTC

As you can see with this dependency, you just need to install
systemd-shim. No need to install systemd-sysv!
The default (systemd-sysv) was just a poor choice from aptitude.

Sorry, I mixed up with another problem that occurred with previous
versions. I have no problems on my Debian/unstable machines
(libpam-systemd still depends on systemd-sysv | systemd-shim),
but I've just realized that the reason is that I temporarily
blocked systemd upgrades for another reason. This is probably
the best thing to do because seeing how things evolve.
--
Vincent Lefèvre <***@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@xvii.vinc17.org

Cameron Norman

2014-07-23 02:51:51 UTC

El Tue, 22 de Jul 2014 a las 4:39 PM, Vincent Lefevre

Post by Julian Gilbey

depends on

Post by Julian Gilbey
systemd-sysv rather than systemd-sysv | systemd-shim.

As you can see with this dependency, you just need to install
systemd-shim. No need to install systemd-sysv!
The default (systemd-sysv) was just a poor choice from aptitude.

I used this apt preferences part to keep systemd back to version 204
until systemd-shim is updated:

Package: systemd libsystemd-* libpam-systemd
Pin: version 204*
Pin-Priority: 1001

I noticed that not doing the libraries cause apt to try to upgrade them
on dist-upgrade and do some weird operations like try to remove my
current init system and install systemd-sysv or remove all of systemd,
as well as NM and udisks and a lot of other packages.

Best wishes,
--
Cameron Norman

Thorsten Glaser

2014-07-23 10:33:59 UTC

Post by Cameron Norman
I noticed that not doing the libraries cause apt to try to upgrade them
on dist-upgrade and do some weird operations like try to remove my
current init system and install systemd-sysv or remove all of systemd,
as well as NM and udisks and a lot of other packages.

FWIW, there¹⁴ is now a prevent-systemd-running package which only
Conflicts: live-config-systemd, systemd-cron, systemd-sysv, systemd-ui
and thus will keep all those packages you mentioned installed.
Since it is “Important: yes”, it probably²³ prevents APT from wanting
to upgrade those library packages.

① http://users.unixforge.de/~tglaser/debs/debidx.htm
built from the “mirabilos-support” source package.

② I do not have prevent-systemd-running installed,
only the harsher versions.

③ But the new contrib/prevent-nvidia-removal metapackage
did prevent xserver-xorg-video-nvidia from being removed
and let APT keep the older X.org installed instead of
wishing to upgrade it, until non-free/nvidia-driver
was updated, which is the same mechanism, so I’m positive
that this will work for you.

④ Thanks to not only Wookey but also XTaran for contributing!

bye,
//mirabilos

--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/lqo32n$8gm$***@ger.gmane.org

Matthias Urlichs

2014-07-22 23:44:39 UTC

Hi,

Post by Julian Gilbey
I need to unlock an encrypted filesystem during boot time by
asking for a password to feed into encfs. But I cannot figure out how
to do this under systemd.

"encfs --extpass=systemd-ask-password" ?

--
-- Matthias Urlichs

Agustin Martin

2014-07-23 17:56:31 UTC

I put old systemd stuff on hold until this is sorted out. Did not notice
any problem with that.

This should be a temporary problem until cgmanager makes its way into sid
and systemd-shim can start uting it.

There were two maintainers trying to package cgmanager independently and
have it into NEW. That was the reason for rejection. Both maintainers are
currently working together to get the cgmanager package ready, even if
merging changes from both sides means some days of delay (See #754910).

--
Agustin

Martin Steigerwald

2014-07-25 12:22:56 UTC

I really hope systemd will soon be able to be co-installed with sysvinit-core
again.

Here is another reason why:

Re: Bug#755989: cfdisk: german help page strangely formatted
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755989#15

(In addition to NFS mounts broken with systemd currently.)

Sure I can go through setting up chroot for that, yet I really think if my
work requires changes in other packages and the recent systemd changes do
require this kind of work, I *help* with these changes, instead of uploading
my changes to unstable *before* the other packages have been fixed.

Especially if its such an disruptive change with all kind of side effects.

I only package some quite easy packages so far and I know its a lot of work to
do good debian packaging, a lot more so with complex stuff like systemd. I know
upload has been announced five month ago or so. But still…

I know I will hold back systemd until this is resolved. I am not yet going
systemd only. By trust in systemd is not deep enough to do this on production
systems. Yes, unstable is unstable, but… but putting in onto selected
production systems for testing allows me to test stuff without investing a lot
of extra time for setting up and using test systems.

Ciao,

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7

Vincent Bernat

2014-07-25 15:03:29 UTC

Post by Martin Steigerwald
Re: Bug#755989: cfdisk: german help page strangely formatted
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755989#15
(In addition to NFS mounts broken with systemd currently.)
Sure I can go through setting up chroot for that, yet I really think if my
work requires changes in other packages and the recent systemd changes do
require this kind of work, I *help* with these changes, instead of uploading
my changes to unstable *before* the other packages have been fixed.

As a DD, you should always use a clean chroot to build everything. It's
not like it's something difficult to do. apt-get install cowbuilder ;
pbuilder create --distribution sid. schroot would be another option.

--
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)

Josh Triplett

2014-07-25 15:47:44 UTC

Post by Martin Steigerwald
Sure I can go through setting up chroot for that, yet I really think if my
work requires changes in other packages and the recent systemd changes do
require this kind of work, I *help* with these changes, instead of uploading
my changes to unstable *before* the other packages have been fixed.

One point of clarification: systemd does not require changes in
systemd-shim or cgmanager. systemd runs just fine with no such changes.
Those packages exist for people who for whatever reason don't want to
run systemd, and that's not something the systemd folks should be
expected to help with (any more than people who don't want to run
systemd would be expected to work on systemd).

The systemd maintainers already held systemd 204 back in unstable for
months waiting for the alternative to become viable.

It's not reasonable to expect every systemd upgrade in unstable/testing
to wait for an alternative init system to keep up. If it does keep up,
great; there's no fundamental reason to *not* want that alternative to
work. If it doesn't, oh well.

- Josh Triplett

Cameron Norman

2014-07-25 16:07:31 UTC

El Fri, 25 de Jul 2014 a las 8:47 AM, Josh Triplett

Post by Josh Triplett

Post by Martin Steigerwald
Sure I can go through setting up chroot for that, yet I really think if my
work requires changes in other packages and the recent systemd
changes do require this kind of work, I *help* with these changes,
instead of uploading my changes to unstable *before* the other
packages have been fixed.

One point of clarification: systemd does not require changes in
systemd-shim or cgmanager. systemd runs just fine with no such changes.
Those packages exist for people who for whatever reason don't want to
run systemd, and that's not something the systemd folks should be
expected to help with (any more than people who don't want to run
systemd would be expected to work on systemd).
The systemd maintainers already held systemd 204 back in unstable for
months waiting for the alternative to become viable.
It's not reasonable to expect every systemd upgrade in
unstable/testing
to wait for an alternative init system to keep up. If it does keep up,
great; there's no fundamental reason to *not* want that alternative to
work. If it doesn't, oh well.

I agree, but would also add that other packages in Debian should at
least try to keep support for other init systems by not depending on
later logind's until systemd-shim is updated. It is clear (I think)
that there are a number of reasons somebody would prefer to use an
alternative init system (including a few unresolved bugs so far), and
packages like GNOME or policykit should support more than just
systemd-sysv.

--
Cameron Norman

j***@joshtriplett.org

2014-07-25 16:38:55 UTC

Post by Cameron Norman
El Fri, 25 de Jul 2014 a las 8:47 AM, Josh Triplett

Post by Josh Triplett

Post by Martin Steigerwald
Sure I can go through setting up chroot for that, yet I really think if my
work requires changes in other packages and the recent systemd
changes do require this kind of work, I *help* with these
changes, instead of uploading my changes to unstable *before*
the other packages have been fixed.

One point of clarification: systemd does not require changes in
systemd-shim or cgmanager. systemd runs just fine with no such changes.
Those packages exist for people who for whatever reason don't want to
run systemd, and that's not something the systemd folks should be
expected to help with (any more than people who don't want to run
systemd would be expected to work on systemd).
The systemd maintainers already held systemd 204 back in unstable for
months waiting for the alternative to become viable.
It's not reasonable to expect every systemd upgrade in
unstable/testing
to wait for an alternative init system to keep up. If it does keep up,
great; there's no fundamental reason to *not* want that alternative to
work. If it doesn't, oh well.

I agree, but would also add that other packages in Debian should at
least try to keep support for other init systems by not depending on
later logind's until systemd-shim is updated. It is clear (I think)
that there are a number of reasons somebody would prefer to use an
alternative init system (including a few unresolved bugs so far),
and packages like GNOME or policykit should support more than just
systemd-sysv.

That's another "best-effort" case: if those packages don't need features
of new logind or systemd, they certainly shouldn't gratuitously depend
on a newer version than they need. But if they do, they should properly
express that dependency.

As for "a few unresolved bugs", that's also common in unstable, and I'm
sure they'll get fixed soon enough. Which ones did you have in mind at
the moment? Most of them have been fixed already. The most significant
outstanding ones I know of are 753589 (which has a patch that needs
uploading), 618862 (keyscript support in crypttab), and 738965 (which is
*caused* by a Debian-specific patch).

Long-term, if a non-systemd init remains viable, people running it in
unstable and potentially in testing should likely get used to having to
put large swaths of their system on hold while waiting for updates.
That's a pretty common thing to need to do in unstable.

- Josh Triplett

--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@cloud

Tollef Fog Heen

2014-07-25 16:56:06 UTC

]] Martin Steigerwald

How long are do you think is reasonable to wait then? Back in the big
discussion during the winter, I said we'd want to update around Easter
time. That left four-ish months for those who wanted to have a logind
that would work without systemd as pid in. We ended up updating in
early July, which means we're talking about six months or so of warning.

I think there are other people who have simply failed to act at anything
resembling a reasonable pace and that you are putting the blame in the
wrong place.

We want to make sure this actually works well for the people who use the
default init system, after all, and there's a freeze coming up.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Steve Langasek

2014-07-25 17:23:02 UTC

Post by Tollef Fog Heen
]] Martin Steigerwald

How long are do you think is reasonable to wait then?

For the specific case of a change that makes basic desktop functions
unusable between upgrade and reboot (including the "reboot" button itself),
the right answer is "until it's ready, and if you want it sooner then help."

systemd-shim 6-4 has now been uploaded to unstable with a dependency on
cgmanager, implementing the new post-v205 interfaces. libpam-systemd now
needs to be updated to depend again on systemd-shim (>= 6-4) | systemd-sysv.

Michael Biebl has said on IRC that he will take care of this in the next
upload of systemd.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Martin Steigerwald

2014-07-25 17:59:54 UTC

Post by Tollef Fog Heen
]] Martin Steigerwald

Post by Martin Steigerwald
Sure I can go through setting up chroot for that, yet I really think if my
work requires changes in other packages and the recent systemd changes do
require this kind of work, I *help* with these changes, instead of
uploading my changes to unstable *before* the other packages have been
fixed.>

How long are do you think is reasonable to wait then?

That is exactly the point I was trying to make.

Post by Steve Langasek
systemd-shim 6-4 has now been uploaded to unstable with a dependency on
cgmanager, implementing the new post-v205 interfaces. libpam-systemd now
needs to be updated to depend again on systemd-shim (>= 6-4) | systemd-sysv.
Michael Biebl has said on IRC that he will take care of this in the next
upload of systemd.

Thank you.

Ciao,

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7

Michael Biebl

2014-07-25 18:19:14 UTC

Post by Tollef Fog Heen
]] Martin Steigerwald

How long are do you think is reasonable to wait then?

For the specific case of a change that makes basic desktop functions
unusable between upgrade and reboot (including the "reboot" button itself),

Well, systemd-shim doesn't solve that problem either.
The policykit package in wheezy uses ConsoleKit as backend.
So if you're logged into your wheezy desktop, you only have a CK session
registered. Installing systemd-shim doesn't magically register an active
logind session.

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Steve Langasek

2014-07-25 18:44:41 UTC

Post by Tollef Fog Heen
]] Martin Steigerwald

How long are do you think is reasonable to wait then?

For the specific case of a change that makes basic desktop functions
unusable between upgrade and reboot (including the "reboot" button itself),

Correct. But it's well-established that, when you upgrade your system,
things may be broken in a currently logged-in desktop session until you
log out and log back in.

The difference here is that, without systemd-shim, logging out and logging
back in still does not give the user a working session, you would have to
completely reboot instead. I think this is an important difference in the
quality of the upgrade experience.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Russ Allbery

2014-07-25 19:45:07 UTC

Post by Steve Langasek
The difference here is that, without systemd-shim, logging out and
logging back in still does not give the user a working session, you
would have to completely reboot instead. I think this is an important
difference in the quality of the upgrade experience.

Ah, *that's* what you're getting at. Yes, while we can argue about
severity, I agree that's a regression from the previous state of things.

--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>

Michael Biebl

2014-07-25 20:46:45 UTC

Post by Steve Langasek
Correct. But it's well-established that, when you upgrade your system,
things may be broken in a currently logged-in desktop session until you
log out and log back in.

The release notes actually mention that the system should *not* be
upgraded from within an X session [1] which renders the point about
broken reboot buttons kinda moot.

The release notes also clearly say, that the system should be rebooted
after a dist-upgrade.

[1]
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgrade-preparations

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Steve Langasek

2014-07-25 21:31:36 UTC

Post by Steve Langasek
Correct. But it's well-established that, when you upgrade your system,
things may be broken in a currently logged-in desktop session until you
log out and log back in.

The release notes actually mention that the system should *not* be
upgraded from within an X session

That is a bug in the release notes, dating back to the days when X itself
was unreliable enough that you couldn't be confident that it wouldn't bomb
out leaving dpkg in an unclean state.

Nowadays it is reliable, and a desktop user should never need to see a Linux
console, including during upgrades.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Russ Allbery

2014-07-25 18:42:16 UTC

Post by Steve Langasek
For the specific case of a change that makes basic desktop functions
unusable between upgrade and reboot (including the "reboot" button
itself), the right answer is "until it's ready, and if you want it
sooner then help."

I continue to be baffled by people's apparent belief that this happening
during a major upgrade is some sort of regression. Having those buttons
not work after a major component upgrade, until the X session was
restarted, has been typical behavior for as long as I've been using Debian
with a desktop environment.

--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>

Steve Langasek

2014-07-25 19:20:16 UTC

The distinction is between having to restart your *session* and having to
restart your *system*. The systemd/logind issue introduces a requirement
for the latter, which /is/ a regression.

I can't imagine how anyone can simultaneously hold the view that Debian
should use systemd for improved integration with end-user-targeted desktop
environments, and believe that Debian should leave these end users grubbing
around on the console to do something as fundamental as rebooting their
system after upgrade.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Russ Allbery

2014-07-25 19:50:53 UTC

Post by Russ Allbery
I continue to be baffled by people's apparent belief that this
happening during a major upgrade is some sort of regression. Having
those buttons not work after a major component upgrade, until the X
session was restarted, has been typical behavior for as long as I've
been using Debian with a desktop environment.

The distinction is between having to restart your *session* and having
to restart your *system*. The systemd/logind issue introduces a
requirement for the latter, which /is/ a regression.

Yeah, I just figured that out. I agree that's a regression.

Post by Steve Langasek
I can't imagine how anyone can simultaneously hold the view that Debian
should use systemd for improved integration with end-user-targeted
desktop environments, and believe that Debian should leave these end
users grubbing around on the console to do something as fundamental as
rebooting their system after upgrade.

This confuses me, however. Surely the difference between a one-time
disruption and ongoing pain is too obvious to need stating?

--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>

Steve Langasek

2014-07-25 20:23:58 UTC

This confuses me, however. Surely the difference between a one-time
disruption and ongoing pain is too obvious to need stating?

consolekit was never an ongoing pain for the end users, it was ongoing pain
for the developers and maintainers. Shunting the pain from the maintainers
to the users is always a bug. Not always a fixable bug, but nevertheless
not something we should be sanguine about.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Michael Biebl

2014-07-25 20:00:07 UTC

Post by Steve Langasek
I can't imagine how anyone can simultaneously hold the view that Debian
should use systemd for improved integration with end-user-targeted desktop
environments, and believe that Debian should leave these end users grubbing
around on the console to do something as fundamental as rebooting their
system after upgrade.

You can always reboot from your display manager.
All the major ones in Debian support that.

So no, that's simply incorrect: users don't need to switch to the
console to reboot their system after a dist-upgrade.

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael Biebl

2014-07-25 20:18:23 UTC

Post by Steve Langasek
I can't imagine how anyone can simultaneously hold the view that Debian
should use systemd for improved integration with end-user-targeted desktop
environments, and believe that Debian should leave these end users grubbing
around on the console to do something as fundamental as rebooting their
system after upgrade.

You can always reboot from your display manager.

And we already concluded that you need to logout anyway, even with
systemd-shim. A reboot and relogin isn't that much different from a
users POV.

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Vincent Lefevre

2014-07-25 20:43:45 UTC

Post by Michael Biebl
And we already concluded that you need to logout anyway, even with
systemd-shim. A reboot and relogin isn't that much different from a
users POV.

Screen sessions, SSH sessions and computation processes running in
background are lost after a reboot, not after a relogin.
--
Vincent Lefèvre <***@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@xvii.vinc17.org

Michael Biebl

2014-07-25 21:04:55 UTC

Post by Michael Biebl
And we already concluded that you need to logout anyway, even with
systemd-shim. A reboot and relogin isn't that much different from a
users POV.

Screen sessions, SSH sessions and computation processes running in
background are lost after a reboot, not after a relogin.

You are doing a dist-upgrade while there are running computation
processes? That sounds like a recipe for disaster.

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Vincent Lefevre

2014-07-25 23:25:26 UTC

Post by Michael Biebl
And we already concluded that you need to logout anyway, even with
systemd-shim. A reboot and relogin isn't that much different from a
users POV.

Screen sessions, SSH sessions and computation processes running in
background are lost after a reboot, not after a relogin.

You are doing a dist-upgrade while there are running computation
processes? That sounds like a recipe for disaster.

I have a Debian/unstable desktop machine that permanently runs
computation processes, so yes. However I don't really mind if
they are aborted. I'm more annoyed when losing my screen and SSH
sessions (to the machine). Now, if this happens only once every
few months, that's OK.

What I really meant is that a reboot is quite different from a
relogin: I log out / in again quite often, and if I need a more
permanent session, I use screen.
--
Vincent Lefèvre <***@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@xvii.vinc17.org

Thorsten Glaser

2014-07-28 10:32:00 UTC

Post by Vincent Lefevre
Screen sessions, SSH sessions and computation processes running in
background are lost after a reboot, not after a relogin.

AIUI this is not true for systemd: once the "session" is
terminated, all background processes run in it are killed
too. There are lots of duckduckgo results for "systemd
screen session" where people describe systemd killing their
GNU screen sessions, changing config files to avoid it,
only for the next systemd upgrade to kill their GNU screen
sessions again.

But if this is fixed/solved in Debian, do tell. (And if it
is not, I consider it a catastrophic failure.)

bye,
//mirabilos

Ansgar Burchardt

2014-07-28 10:50:51 UTC

Hi,

Post by Thorsten Glaser

Post by Vincent Lefevre
Screen sessions, SSH sessions and computation processes running in
background are lost after a reboot, not after a relogin.

AIUI this is not true for systemd: once the "session" is
terminated, all background processes run in it are killed
too.

No, systemd doesn't kill any background processes (though one can change
the configuration to do so if desired).

Ansgar

Charles Plessy

2014-07-28 13:35:17 UTC

Post by Thorsten Glaser
There are lots of duckduckgo results for "systemd
screen session" where people describe systemd killing their
GNU screen sessions, changing config files to avoid it,
only for the next systemd upgrade to kill their GNU screen
sessions again.

Really ? At least not that much in the top of the list.

curl 'https://duckduckgo.com/html/?q=systemd%20screen%20session' | lynx --stdin --dump

[…]

[6]archlinux wiki systemd/User - ArchWiki
systemd offers users the ability to run an instance of systemd to
manage their session and services. This allows users to start, stop,
enable, and disable units found within certain directories when systemd
is run by the user.
wiki.archlinux.org/index.php/Systemd/User

Not a problem

[7]How To Use Linux Screen - Server Management Services
Linux Screen allows you to: Use multiple shell windows from a single
SSH session. Keep a shell active even through network disruptions.
Disconnect and re-connect to a shell sessions from multiple locations.
rackaid.com/blog/linux-screen-tutorial-and-how-to/

Nothing to do with systemd

[8][systemd-devel] [beagleboard] Systemd blowing away screen ...
Adding the systemd list. I had this working a few systemd releases ago,
but I now get the same behaviour as you are seeing. Op 22 mrt. 2012, om
08:32 heeft Ken Restivo het volgende geschreven: > Systemd wipes out
screen sessions, thus making screen unusable.
lists.freedesktop.org/archives/systemd-devel/2012-March/004774....

Sent in 2012

[9]GNU Screen - ArchWiki - Arch Linux
$ screen -x session_name Autostart with systemd. This service
autostarts screen for the specified user (e.g. systemctl enable
***@florian). ... To send a command to the inner screen session, use
ctrl+a a, followed by your command. For example:
wiki.archlinux.org/index.php/GNU_Screen

Not a problem

[10]screen - systemd service that needs .ssh/id_dsa password ...
I have a systemctl service that starts a process smd-loop in a screen
session. This process requires acces to remote SSH sources (for syncing
purposes) and thus needs to be able to access my id_dsa private key.
unix.stackexchange.com/questions/53044/systemd-service-that-need...

Not related to your problem

[11][SOLVED] Console font ignored after switching to systemd ...
Newbie Corner ... "Kebertx Member Registered: 2012-01-02 Posts: 69
[SOLVED] Console font ignored after ..." · "jasonwryan Administrator
From: .nz Registered: 2009-05-09 Posts: 11,656 Website Re: [SOLVED]
Console font ignored after switching to systemd Try it without the
quotes, as per the man ...
bbs.archlinux.org/viewtopic.php?id=151233

Not related to your problem

[12]rTorrent+Screen doesn't start properly from systemd ...
I think that the user session works just like the system session. So
when it starts systemd --user, it will just start whatever it deems the
default.target.
linuxine.com/story/rtorrentscreen-doesnt-start-properl...

Not related to your problem

[13]Using screen for remote interaction | Linux.com
Basically, screen allows you to create virtual terminals which are not
connected to your actual xterms or console screens. You can then
disconnect from a screen session and reconnect from somewhere else
while preserving your shell or other running processes.
linux.com/learn/tutorials/442418-using-screen-for-r...

Nothing to do with systemd

[14]STOP:c000021a(Fatal System Error) The Session Manager ...
original title: STOP:c000021a(Fatal System Error) The Session Manager
Initialization system process terminated unexpectedly with a status of
0xc000026c (0x00000000 0x00000000) The system has been shut ... the
first non-bsod start of windows hanged on a please wait screen.
answers.microsoft.com/en-us/windows/forum/windows_xp-system/sto...

Not likely to use systemd in the near future

[15]GNU Screen - Wikipedia, the free encyclopedia
GNU Screen is a software application that can be used to multiplex
several virtual consoles, allowing a user to access multiple separate
terminal sessions inside a single terminal window or remote terminal
session.
en.wikipedia.org/wiki/GNU_Screen

Not related to your problem

[16]How to send a command to a screen session? - LinuxQuestions.org
Thx for the answer. I tried to make a system() call to a screen -x
sessionname redirecting the output to /dev/null, but it didn't work. I
found out that I could send the screen -x sessionname command to
another (temporarily) screen session, but that didn't work neither (see
below).
linuxquestions.org/questions/linux-software-2/how-to-send-a-...
[17]Screen User's Manual - GNU
1 Overview. Screen is a full-screen window manager that multiplexes a
physical terminal between several processes, typically interactive
shells.

Not related to your problem

…

And a more precise “https://duckduckgo.com/html/?q=%22systemd%20screen%20session%22”
reports no result.

Can you please stop to pollute this list each time there is ‘systemd’ in the
subject ?

Steve Langasek

2014-07-25 20:25:56 UTC

Post by Steve Langasek
I can't imagine how anyone can simultaneously hold the view that Debian
should use systemd for improved integration with end-user-targeted desktop
environments, and believe that Debian should leave these end users grubbing
around on the console to do something as fundamental as rebooting their
system after upgrade.

You can always reboot from your display manager.
All the major ones in Debian support that.
So no, that's simply incorrect: users don't need to switch to the
console to reboot their system after a dist-upgrade.

If that's so, then I stand corrected. I assumed this would fail from the DM
as well as from the desktop.

AIUI other functions, such as suspending the laptop, still fail with
systemd alone until you reboot. And we do have the means to address this
now.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Michael Biebl

2014-07-25 21:10:41 UTC

Post by Steve Langasek
systemd-shim 6-4 has now been uploaded to unstable with a dependency on
cgmanager, implementing the new post-v205 interfaces.

I just installed systemd-shim 6-4 and cgmanager 0.28-1.
Unfortunately the cgmanager package seems to be not quite ready yet.

The init script fails with

# service cgmanager start
[....] Starting cgroup management daemon: cgmanagercgmanager: Failed
mounting memory onto /run/cgmanager/fs/memory: No such file or directory
cgmanager: Failed mounting cgroups
cgmanager: Failed to set up cgroup mounts
. ok

on a default jessie kernel.

Interestingly, the return code of the init script was 0.

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Adam D. Barratt

2014-07-25 21:31:56 UTC

Post by Michael Biebl
I just installed systemd-shim 6-4 and cgmanager 0.28-1.
Unfortunately the cgmanager package seems to be not quite ready yet.
The init script fails with
# service cgmanager start
[....] Starting cgroup management daemon: cgmanagercgmanager: Failed
mounting memory onto /run/cgmanager/fs/memory: No such file or directory
cgmanager: Failed mounting cgroups
cgmanager: Failed to set up cgroup mounts
. ok

That's #755990, which was fixed a couple of hours ago.

Regards,

Adam

Serge Hallyn

2014-07-25 21:35:03 UTC

Post by Steve Langasek
systemd-shim 6-4 has now been uploaded to unstable with a dependency on
cgmanager, implementing the new post-v205 interfaces.

I just installed systemd-shim 6-4 and cgmanager 0.28-1.
Unfortunately the cgmanager package seems to be not quite ready yet.
The init script fails with
# service cgmanager start
[....] Starting cgroup management daemon: cgmanagercgmanager: Failed
mounting memory onto /run/cgmanager/fs/memory: No such file or directory
cgmanager: Failed mounting cgroups
cgmanager: Failed to set up cgroup mounts
. ok

That was an upstream bug, should be fixed in 0.28-2. The default of
having memory show up in /proc/cgroups but not be mountable was being
mishandled.

There was also mention of having a systemd unit linked to /dev/null to
not run cgmanager in systemd. I assume that's what systemd itself would
actually prefer and I'm fine with it, but for the sake of supporting
nested containers it would be nicer if we could have it actually run
(for now).

Post by Michael Biebl
on a default jessie kernel.
Interestingly, the return code of the init script was 0.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael Biebl

2014-07-25 21:44:43 UTC

Hi Serge!

Post by Serge Hallyn

Post by Steve Langasek
systemd-shim 6-4 has now been uploaded to unstable with a dependency on
cgmanager, implementing the new post-v205 interfaces.

I just installed systemd-shim 6-4 and cgmanager 0.28-1.
Unfortunately the cgmanager package seems to be not quite ready yet.
The init script fails with
# service cgmanager start
[....] Starting cgroup management daemon: cgmanagercgmanager: Failed
mounting memory onto /run/cgmanager/fs/memory: No such file or directory
cgmanager: Failed mounting cgroups
cgmanager: Failed to set up cgroup mounts
. ok

That was an upstream bug, should be fixed in 0.28-2. The default of
having memory show up in /proc/cgroups but not be mountable was being
mishandled.

Ah perfect. Seems this just hasn't hit the archive yet when I installed
cgmanager.

Steve, could you please bump the depends on cgmanager in systemd-shim
accordingly to ensure a working cgmanager is installed?

Post by Serge Hallyn
There was also mention of having a systemd unit linked to /dev/null to
not run cgmanager in systemd. I assume that's what systemd itself would
actually prefer and I'm fine with it, but for the sake of supporting
nested containers it would be nicer if we could have it actually run
(for now).

If cgmanager and systemd don't step on each others toes and there is
value running cgmanager besides systemd, it might make sense to also run
it under systemd.

My only concern would be, that most users probably don't need nested
containers and if cgmanager is pulled in as a depends on systemd-shim,
they'd have a useless daemon running.

What about shipping a native .service file for cgmanager, but not enable
it by default, i.e. the admin would have to run
systemctl enable cgmanager.service
if want's to run cgmanager under systemd.

That means, under sysvinit the service would be running by default and
under systemd it would have to be enabled explicitly.

Would that work for you?

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Serge Hallyn

2014-07-25 22:10:22 UTC

Post by Michael Biebl
Hi Serge!

Post by Serge Hallyn

Post by Steve Langasek
systemd-shim 6-4 has now been uploaded to unstable with a dependency on
cgmanager, implementing the new post-v205 interfaces.

I just installed systemd-shim 6-4 and cgmanager 0.28-1.
Unfortunately the cgmanager package seems to be not quite ready yet.
The init script fails with
# service cgmanager start
[....] Starting cgroup management daemon: cgmanagercgmanager: Failed
mounting memory onto /run/cgmanager/fs/memory: No such file or directory
cgmanager: Failed mounting cgroups
cgmanager: Failed to set up cgroup mounts
. ok

That was an upstream bug, should be fixed in 0.28-2. The default of
having memory show up in /proc/cgroups but not be mountable was being
mishandled.

Ah perfect. Seems this just hasn't hit the archive yet when I installed
cgmanager.
Steve, could you please bump the depends on cgmanager in systemd-shim
accordingly to ensure a working cgmanager is installed?

If cgmanager and systemd don't step on each others toes and there is
value running cgmanager besides systemd, it might make sense to also run
it under systemd.
My only concern would be, that most users probably don't need nested
containers and if cgmanager is pulled in as a depends on systemd-shim,
they'd have a useless daemon running.
What about shipping a native .service file for cgmanager, but not enable
it by default, i.e. the admin would have to run
systemctl enable cgmanager.service
if want's to run cgmanager under systemd.
That means, under sysvinit the service would be running by default and
under systemd it would have to be enabled explicitly.
Would that work for you?

Sure - I don't know offhand how this would be done, but I'll look into it.

Steve Langasek

2014-07-25 22:14:26 UTC

Post by Michael Biebl
Ah perfect. Seems this just hasn't hit the archive yet when I installed
cgmanager.
Steve, could you please bump the depends on cgmanager in systemd-shim
accordingly to ensure a working cgmanager is installed?

No, I'm not going to reupload the package to declare an incompatibility with
a version of a dependency that was in unstable less than a day before
getting fixed.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Russ Allbery

2014-07-25 22:43:38 UTC

No, I'm not going to reupload the package to declare an incompatibility with
a version of a dependency that was in unstable less than a day before
getting fixed.

I concur -- not every bug is worth tightening dependencies.

--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>

Michael Biebl

2014-07-25 21:51:32 UTC

Post by Michael Biebl
The init script fails with
# service cgmanager start
[....] Starting cgroup management daemon: cgmanagercgmanager: Failed
mounting memory onto /run/cgmanager/fs/memory: No such file or directory
cgmanager: Failed mounting cgroups
cgmanager: Failed to set up cgroup mounts
. ok
on a default jessie kernel.
Interestingly, the return code of the init script was 0.

Could you please also look into this.

The init script shouldn't have an exit code of 0 if the daemon failed to
start.

Thanks!

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Serge Hallyn

2014-07-25 22:06:36 UTC

Could you please also look into this.
The init script shouldn't have an exit code of 0 if the daemon failed to
start.
Thanks!

D'oh, yup, that's a real bug in the (upstream) sysvinit job. Thanks.

Steve Langasek

2014-07-25 21:50:51 UTC

Post by Steve Langasek
systemd-shim 6-4 has now been uploaded to unstable with a dependency on
cgmanager, implementing the new post-v205 interfaces.

I just installed systemd-shim 6-4 and cgmanager 0.28-1.
Unfortunately the cgmanager package seems to be not quite ready yet.
The init script fails with
# service cgmanager start
[....] Starting cgroup management daemon: cgmanagercgmanager: Failed
mounting memory onto /run/cgmanager/fs/memory: No such file or directory
cgmanager: Failed mounting cgroups
cgmanager: Failed to set up cgroup mounts
. ok
on a default jessie kernel.

I believe this is bug #755990, already fixed by Serge in 0.28-2.

Post by Michael Biebl
Interestingly, the return code of the init script was 0.

Hmm, dunno about that. Serge?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Cameron Norman

2014-07-25 22:17:36 UTC

El Fri, 25 de Jul 2014 a las 2:50 PM, Steve Langasek

Post by Steve Langasek
systemd-shim 6-4 has now been uploaded to unstable with a

dependency on

Post by Steve Langasek
cgmanager, implementing the new post-v205 interfaces.

I just installed systemd-shim 6-4 and cgmanager 0.28-1.
Unfortunately the cgmanager package seems to be not quite ready yet.
The init script fails with
# service cgmanager start
[....] Starting cgroup management daemon: cgmanagercgmanager: Failed
mounting memory onto /run/cgmanager/fs/memory: No such file or directory
cgmanager: Failed mounting cgroups
cgmanager: Failed to set up cgroup mounts
. ok
on a default jessie kernel.

I believe this is bug #755990, already fixed by Serge in 0.28-2.

Post by Steve Langasek
Interestingly, the return code of the init script was 0.

Hmm, dunno about that. Serge?

Oh this is easy. The init script calls s-s-d and does not check the
return code (so always exits 0). I am just going to use set -e in the
init script, only a couple tweaks are needed. I will get a merge
request to the github repo in about 15 minutes.

Cheers,
--
Cameron Norman

Russ Allbery

2014-07-25 22:42:54 UTC

Oh this is easy. The init script calls s-s-d and does not check the return
code (so always exits 0). I am just going to use set -e in the init
script, only a couple tweaks are needed.

Please don't use set -e in init scripts. See Policy 9.3.2:

Be careful of using set -e in init.d scripts. Writing correct init.d
scripts requires accepting various error exit statuses when daemons
are already running or already stopped without aborting the init.d
script, and common init.d function libraries are not safe to call with
set -e in effect. For init.d scripts, it's often easier to not use
set -e and instead check the result of each command separately.

Not mentioned there is another problem, namely that LSB mandates
particular exit codes for particular conditions in init scripts, and set
-e will not produce the correct exit codes.

--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>

Cameron Norman

2014-07-25 23:08:50 UTC

Oh this is easy. The init script calls s-s-d and does not check the return
code (so always exits 0). I am just going to use set -e in the init
script, only a couple tweaks are needed.

Be careful of using set -e in init.d scripts. Writing correct init.d
scripts requires accepting various error exit statuses when daemons
are already running or already stopped without aborting the init.d
script, and common init.d function libraries are not safe to call with
set -e in effect. For init.d scripts, it's often easier to not use
set -e and instead check the result of each command separately.
Not mentioned there is another problem, namely that LSB mandates
particular exit codes for particular conditions in init scripts, and set
-e will not produce the correct exit codes.

I thought that start-stop-daemon (and status_of_proc) returned the
correct codes, and whatever it returns you can relay / let the shell
catch? The script is here
(https://github.com/cgmanager/cgmanager/pull/14/files), if you wanted
to take a look.

Best,
--
Cameron Norman

Russ Allbery

2014-07-25 23:19:18 UTC

Post by Cameron Norman
I thought that start-stop-daemon (and status_of_proc) returned the
correct codes, and whatever it returns you can relay / let the shell
catch? The script is here
(https://github.com/cgmanager/cgmanager/pull/14/files), if you wanted to
take a look.

It does not, at least not the way that you're calling it.

If you used --oknodo in a few places, it might be closer, but take a look
at /etc/init.d/skeleton and look at the exit status remapping that it
does.

--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>

Vincent Bernat

2014-07-26 06:28:54 UTC

It does not, at least not the way that you're calling it.
If you used --oknodo in a few places, it might be closer, but take a look
at /etc/init.d/skeleton and look at the exit status remapping that it
does.

Some time ago, /etc/init.d/skeleton has been modified to make use of
init-d-script.

--
printk("Entering UltraSMPenguin Mode...\n");
2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c

Serge Hallyn

2014-07-25 23:37:10 UTC

Oh this is easy. The init script calls s-s-d and does not check the return
code (so always exits 0). I am just going to use set -e in the init
script, only a couple tweaks are needed.

No worries, I've gone a different route - borrowing heavily (and
appreciatively) from the libvirt init scripts.

Marco d'Itri

2014-07-26 15:55:48 UTC

Post by Russ Allbery
Not mentioned there is another problem, namely that LSB mandates
particular exit codes for particular conditions in init scripts, and set
-e will not produce the correct exit codes.

What a great argument in favour of systemd... :-)

--
ciao,
Marco

Michael Biebl

2014-07-25 23:08:57 UTC

Just a quick followup: After testing cgmanager a bit I stumbled over
various issues which should be fixed first before I'm going to re-add
the alternative dependency. I started filing bugs for them.

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Steve Langasek

2014-08-02 02:11:24 UTC

Just a quick followup: After testing cgmanager a bit I stumbled over
various issues which should be fixed first before I'm going to re-add
the alternative dependency. I started filing bugs for them.

Thanks for identifying these bugs.

The only bugs still open on cgmanager are a pair of normal-severity bugs.
What is blocking libpam-systemd re-adding the systemd-shim alternative
dependency now? It's not reasonable to withhold this alternative until
cgmanager and/or systemd-shim are entirely bug-free by your reckoning.
Users should have the option to install systemd-shim+libpam-systemd instead
of systemd-sysv, even if that means there are some non-RC bugs.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

Michael Biebl

2014-08-07 09:39:44 UTC

Post by Steve Langasek
Thanks for identifying these bugs.
The only bugs still open on cgmanager are a pair of normal-severity bugs.
What is blocking libpam-systemd re-adding the systemd-shim alternative
dependency now? It's not reasonable to withhold this alternative until
cgmanager and/or systemd-shim are entirely bug-free by your reckoning.
Users should have the option to install systemd-shim+libpam-systemd instead
of systemd-sysv, even if that means there are some non-RC bugs.

systemd 208-7 has been uploaded re-adding support for making logind
D-Bus activatable and re-adding the alternative dependency on systemd-shim.

There is still one rather important bug [1] which needs to be adressed
in systemd-shim, but we uploaded systemd with the alternative
nonetheless as you requested. It is not the intention of the pkg-systemd
team to withhold any alternative.
I'm sure you'll deal with [1] appropriately.

Cheers,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756076

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael Biebl

2014-07-27 20:53:48 UTC

Julian, do you still need help with that?
I've just cobbled together a short unlock.service file which seems to
work reasonable fine and which I can share with you.

We can further discuss this on pkg-systemd-maintainers if you want.

Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Christian Hofstaedtler

2014-07-27 23:54:54 UTC

Julian, do you still need help with that?
I've just cobbled together a short unlock.service file which seems to
work reasonable fine and which I can share with you.

I'd love to see that file.

C.

--
,''`. Christian Hofstaedtler <zeha-8fiUuRrzOP0dnm+***@public.gmane.org>
: :' : Debian Developer
`. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03
`-

Michael Biebl

2014-07-28 14:53:36 UTC

Post by Christian Hofstaedtler

Hi,

Julian, do you still need help with that?
I've just cobbled together a short unlock.service file which seems to
work reasonable fine and which I can share with you.

I'd love to see that file.

Here we go:

------8<-----------
[Unit]
Description=Unlock EncFS
DefaultDependencies=no
After=local-fs.target
Before=display-manager.service getty-2yfe/R6NngVTDjBF/***@public.gmane.org

[Service]
Type=oneshot
RemainAfterExit=true
Environment=RootDir=/home/.encfs/crypt
Environment=MountPoint=/home/crypt
ExecStart=/bin/sh -c "systemd-ask-password --no-tty --timeout=30 'Unlock
EncFS' | encfs --stdinpass $RootDir $MountPoint"
ExecStop=/bin/umount $MountPoint

[Install]
WantedBy=sysinit.target
------>8-----------

(The ExecStart= needs to be a single line, I hope it's not messed up by
my mailer)

I've installed that as /etc/systemd/system/unlock.service, then ran
"systemctl enable unlock.service"

A few remarks:

- I hook that service up in sysinit.target, which is similar to rcS in
sysvinit since that is what Julian was using in his original SysV init
script
Services which run that early should usually use DefaultDependencies=no
and specificy their requirements explicitly (that's what the
After=local-fs.target is for)

- I used Type=oneshot, as I'm only interested in the unlock process and
not in tracking the encfs process.

- The usage of Environment= is entirely optional, but makes it a bit
more readable

- The ExecStop= is not strictly required, but simply a nice touch.

- Querying input on a non sequential system (like systemd) is not
trivial. I therefore recommend the usage of plymouth. Don't consider it
as only a shiny bootsplash, but rather an I/O multi-plexer [1]. If you
insist on not using plymouth, make at least sure, to booth with "quiet"
enabled, otherwise your unlock prompt will be overwritten by the boot
messages.
Let me repeat: for such case, I really recommend to use plymouth!

- The Before=display-manager.service getty-2yfe/R6NngVTDjBF/***@public.gmane.org line makes sure,
your plymouth (or console) prompt is not interfered by the getty on tty1
or X/your display manager.
Not all display managers already setup the display-manager.service
symlink properly (gdm3 in unstable and lightdm, do).
So you might need to change that to list the actual service name say you
use xdm:
Before=xdm.service ...

systemd-ask-password is clever enough to automatically use plymouth when
available or falls back to the tty agent otherwise.

If you have further questions, just ask.

Cheers,
Michael

[1] http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/
(currently not reachable, you might use the google cache)

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael Biebl

2014-07-28 15:21:29 UTC

Post by Michael Biebl
------8<-----------
[Unit]
Description=Unlock EncFS
DefaultDependencies=no
After=local-fs.target
[Service]
Type=oneshot
RemainAfterExit=true
Environment=RootDir=/home/.encfs/crypt
Environment=MountPoint=/home/crypt
ExecStart=/bin/sh -c "systemd-ask-password --no-tty --timeout=30 'Unlock
EncFS' | encfs --stdinpass $RootDir $MountPoint"
ExecStop=/bin/umount $MountPoint
[Install]
WantedBy=sysinit.target
------>8-----------

To show you some additional cool systemd features, I'm going a step
further and make this unit file a completely generic template unit, so
it can easily be re-used, say if you have multiple encfs file systems to
unlock and you don't want to copy that file over and over again.

Only 3 small modifications are necessary:
- Rename the file ***@.service
- Update Description: Description=Unlock %I EncFS
- Use EnvironmentFile=/etc/encfs/%I

The %I is the instance name specfier and denotes the part between
unlock@<instance name>.service. See man systemd.unit(5)

The resulting template unit looks like this and is completely generic:

------8<-----------
[Unit]
Description=Unlock %I EncFS
DefaultDependencies=no
After=local-fs.target
Before=display-manager.service getty-2yfe/R6NngVTDjBF/***@public.gmane.org

[Service]
Type=oneshot
RemainAfterExit=true
EnvironmentFile=/etc/encfs/%I
ExecStart=/bin/sh -c "systemd-ask-password --no-tty --timeout=30 'Unlock
EncFS' | encfs --stdinpass $RootDir $MountPoint"
ExecStop=/bin/umount $MountPoint

[Install]
WantedBy=sysinit.target
------>8-----------

So how do we create a new encfs unit now?

- mkdir /etc/encfs/
- echo -e "RootDir=/home/.encfs/crypt/\nMountPoint=/home/crypt" >
/etc/encfs/home
- systemctl enable unlock-h0aTa3Zs2uhTDjBF/***@public.gmane.org
Note how the file name and the instance name match.

Hope you enjoy my little explorations in systemd land :-)

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Cameron Norman

2014-07-28 16:20:06 UTC