Re: [systemd-devel] Question regarding systemd behavior during shutdown

2016-11-03 Thread Lennart Poettering
On Thu, 03.11.16 14:01, svk (shreyas...@gmail.com) wrote:

> Hi,
> I have a question regarding systemd behavior during shutdown.
> 
> I am using systemd 219 on a Linux 4.1 kernel(custom distribution). When I
> issue a "shutdown" command I observe something unusual :-

219 is really old, and the behaviour regarding the shutdown
transaction has changed a bit in the past. Any chance you can verify
this with something recent before we look into this?

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-03 Thread Lennart Poettering
On Mon, 26.09.16 07:02, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
> > The emergency mode assumes console access, which requires physical access,
> > which is quiet difficult if the machine is remote.
> 
> It does also assume knowledge of the root password, which is in
> enterprise environments not often the case. Enterprises usually have
> root passwords stowed away in a safe, behind a three-headed guard dog,
> requiring management approval, and > 2 eyes mechanisms, and usually
> have password-changing processes attached that touch other machines
> sharign the same root password as well (for example because the root
> password hash is stamped into the golden image).
> 
> Many enterprise environments that I know have their processes geared
> in a way that the root password is not needed in daily operation.
> Login via ssh key, privilege escalation via sudo.
> 
> systemd requiring the root password because some tertiary file system
> doesn't mount is a nuisance for those environments.
> 
> Some sites have resorted to adding "nofail" to all fstab lines just to
> find themselves with the next issue since the initramfs of some
> distributions doesn't know this option yet. 

"nofail" has been around as long as fstab has been around really. It's
not a systemd invention.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Question regarding systemd behavior during shutdown

2016-11-03 Thread svk
Hi,
I have a question regarding systemd behavior during shutdown.

I am using systemd 219 on a Linux 4.1 kernel(custom distribution). When I
issue a "shutdown" command I observe something unusual :-

If a process managed by a systemd unit file with "Restart=always" exits
prior to receiving a SIGTERM, systemd attempts to restart the service.
However, since the system is shutting down, systemd detects a conflict with
shutdown.target, and declares that the service had entered "failed" state.
Wouldn't it be cleaner to detect this before attempting to execute the
restart job? A service voluntarily exiting during shutdown should not be
considered as a failure.

Sample journal logs with detailed output enabled:-

Sep 22 22:59:34 re0 systemd[1]: foo.service holdoff time over, scheduling
restart.

33937 Sep 22 22:59:34 re0 systemd[1]: Trying to enqueue job
foo.service/restart/fail

Sep 22 22:59:34 re0 systemd[1]: Requested transaction contradicts existing
jobs: Transaction is destructive

Sep 22 22:59:34 re0 systemd[1]:foo.service failed to schedule restart job:
Transaction is destructive.

Sep 22 22:59:34 re0 systemd[1]: foo.service changed auto-restart -> failed
Thanks,
Shreyas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] unsubsribe

2016-11-03 Thread Reindl Harald



Am 03.11.2016 um 21:36 schrieb Douglas R. Reno:


On Thu, Nov 3, 2016 at 3:10 PM, Reindl Harald > wrote:




Am 03.11.2016 um 20:27 schrieb sp113438:

unsubsribe


i can' remember that you asked me or other list memeber to
subscribe you so why should we even be able to unsubscribe you?
guess what the list footer is for


List-Unsubscribe:
 >,
 ?subject=unsubscribe>



sp113438 misspelled Unsubscribe


correct spelling would not have changed the fact that the list-address 
is ust the wrong destination - on every maling lisst - simply by using 
common-sense
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] unsubsribe

2016-11-03 Thread Douglas R. Reno
On Thu, Nov 3, 2016 at 3:10 PM, Reindl Harald 
wrote:

>
>
> Am 03.11.2016 um 20:27 schrieb sp113438:
>
>> unsubsribe
>>
>
> i can' remember that you asked me or other list memeber to subscribe you
> so why should we even be able to unsubscribe you? guess what the list
> footer is for
>
>
> List-Unsubscribe:
>  ,
>  
>
>
sp113438 misspelled Unsubscribe.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Single Start-job remains listed after startup in state waiting ...

2016-11-03 Thread Lennart Poettering
On Fri, 28.10.16 14:55, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote:

> Hello,
> 
> we are observing a weird  behavior with systemd 211.
> 
> The issue:
> 
> -After the startup is finished (multi-user.target is
> -reached), one single job (typ: start, unit: service)
> -remains in the job queue in state waiting

We had an issue with that in the past, please retry with a less
ancient version of systemd, I am pretty sure this was already fixed,
but I can't tell you really when precisely.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] unsubsribe

2016-11-03 Thread sp113438
unsubsribe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] automount unit that never fails?

2016-11-03 Thread Lennart Poettering
On Sat, 29.10.16 14:20, Bjørn Forsman (bjorn.fors...@gmail.com) wrote:

> On 1 October 2016 at 17:14, Bjørn Forsman  wrote:
> > On 20 September 2016 at 09:08, Bjørn Forsman  
> > wrote:
> >> I have a question/issue with the behaviour of (auto)mount units.
> >> [...]
> >
> > Bump.
> 
> Bump again. Anyone?

Your mail does not say in any way what precisely your issue is?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] kexec -p option does not cause a reboot on panic

2016-11-03 Thread Lennart Poettering
On Sat, 29.10.16 00:16, Dey, Megha (megha@intel.com) wrote:

> Hi,
> 
> I was testing kexec on systemd (Ubuntu 16.04). Here are the steps I follow:

systemd is not involved with crash dumping on kernel crashes. Please
contact your distro maintainers or the crash dumping maintainers for
help, we can't really help you there.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-nspawn leaves leftovers in /tmp

2016-11-03 Thread Lennart Poettering
On Thu, 03.11.16 11:34, Bill Lipa (d...@masterleep.com) wrote:

> Hello,
> 
> I am using systemd-nspawn to run a short lived process in a container.
> This is a fairly frequent operation (once every few seconds).  Each
> time systemd-nspawn runs, it leaves a temporary empty directory like
> /tmp/nspawn-root-CPeQjR.  These directories don't seem to get cleaned
> up.
> 
> I'm using systemd 229 on Ubuntu 16.04.  The command line looks like:
> 
> sudo systemd-nspawn -axq --private-network --drop-capability=all -u user
>   --chdir /home/user/work -M ubuntu-16.10 --bind
> /home/outer/work:/home/user/work
> 
> I'm a little worried that there are going to be hundreds of thousands
> of these directories clogging up /tmp after a few weeks.  Is this
> expected?

Generally, temporary files like this should not be left around by
commands that exit cleanly. If they do, then that's a bug, please file
a bug. (but first, please retry on the two most current systemd
versions, we only track issues with those upstream).

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] PAM session hooks for independent session

2016-11-03 Thread Lennart Poettering
On Sat, 29.10.16 18:37, Antoine Martin (anto...@nagafix.co.uk) wrote:

> The pam_systemd is much more difficult to figure out, since I am not
> aware of any other packages does this at present - maybe there are?
> * should we ship a /etc/pam/d/xpra file like this one:
> sessionrequired pam_localuser.so
> sessionsufficient pam_systemd.so class=user type=x11 debug=1
> * we supply VTNR=0 (we don't have a VT..), XDG_SESSION_TYPE=x11,
> XDG_SEAT=0 (not sure this is right) as well as the correct PAM_XDISPLAY
> for the display we've started. But the pam_open_session call fails with:
> pam_systemd(xpra:session): Failed to create session: Access denied
> Probably because of this:

You should not set the vtnr or seat name, if you are fully virtual and
do not manage local hw or local vts.

> [system] Rejected send message, 2 matched rules; type="method_call",
> sender=":1.339" (uid=1001 pid=15738 comm="/bin/python /usr/bin/xpra
> start --systemd-run=yes "
> label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
> interface="org.freedesktop.login1.Manager" member="CreateSession" error
> name="(unset)" requested_reply="0" destination="org.freedesktop.login1"
> (uid=0 pid=1185 comm="/usr/lib/systemd/systemd-logind "
> label="system_u:system_r:systemd_logind_t:s0")
> 
> Where / how can we change the policy to allow sufficiently privileged
> users to create a new session? (which users will get this privilege and
> how this is configured is not entirely clear at this point - can we
> somehow keep this simple using unix group permissions?)
> How is this going to ensure that the cgroup is correct? Isn't that set
> when the process is started?
> 
> Any help or pointers would be much appreciated.

Registering sessions requires privileges. If you want unprivileged
clients to be able to do this, you need to add a security transition
somewhere. This means your tool can either be SUID (which I wouldn't
recommend) or you split your tool in two: a tiny (socket activated)
daemon that does little else than wait for a client request, and when
it gets it, registers the PAM session and drops privs and runs your
virtual display server. Basically what a display manager such as gdm
does, but instead of managing physical seats you'd just instantiate a
virtual x server for each incoming connection.

Ultimately this is the best idea anyway, as you should properly
disconnect the new bg session from the original session, and that
means you should not have a process relationship between your
processes.

Hope this makes sense=

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd-nspawn leaves leftovers in /tmp

2016-11-03 Thread Bill Lipa
Hello,

I am using systemd-nspawn to run a short lived process in a container.
This is a fairly frequent operation (once every few seconds).  Each
time systemd-nspawn runs, it leaves a temporary empty directory like
/tmp/nspawn-root-CPeQjR.  These directories don't seem to get cleaned
up.

I'm using systemd 229 on Ubuntu 16.04.  The command line looks like:

sudo systemd-nspawn -axq --private-network --drop-capability=all -u user
  --chdir /home/user/work -M ubuntu-16.10 --bind
/home/outer/work:/home/user/work

I'm a little worried that there are going to be hundreds of thousands
of these directories clogging up /tmp after a few weeks.  Is this
expected?

Thank you!
Bill Lipa
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel