Re: [systemd-devel] Help writing a user service file that will exec a command upon system sleep

[Richard Maw]

On Mon, Nov 02, 2015 at 09:04:31AM +0100, Lennart Poettering wrote:
> On Wed, 28.10.15 19:30, John (da_audioph...@yahoo.com) wrote:
> 
> > I have a simple bash script that I would like to have a user service
> > file run with an argument when the system enters a sleep or
> > hibernation state but as I understand it, user service units do not
> > use the sleep.target.  The goal is to have the following run before
> > the system goes into sleep/hibernate triggered by whatever mechanism
> > systemd uses to detect when the user sleeps or hibernates the
> > system: '/usr/bin/psd sync'
> 
> You can install a suspend delay inhibitor:
> 
> https://wiki.freedesktop.org/www/Software/systemd/inhibit/
> 
> That works from privileged code the same as for user code. However,
> you cannot really do that from shell code. I fear for shell this is
> simply not available, sorry.

You may be able to abuse the hell out of systemd-inhibit to have it work:

#!/bin/sh
# Approach cribbed from http://www.opopop.net/Harnessing_DBus/
while true; do
# Hold inhibitor lock until dbus signal that preparing to sleep
systemd-inhibit --what=sleep --why="sync psd" sh -c '
dbus-monitor --system 
"interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" |
while read -r line; do
read type value
if [ "$type" = boolean -a "$value" = true ]; then
break
fi
done
/usr/bin/psd sync
'
# Wait for a message saying we're resuming before restarting monitor
dbus-monitor --system 
"interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" |
while read -r line; do
read type value
if [ "$type" = boolean -a "$value" = false ]; then
break
fi
done
done

Though I wouldn't honestly recommend doing it this way.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help writing a user service file that will exec a command upon system sleep

[Mantas Mikulėnas]

On Mon, Nov 2, 2015 at 3:34 PM, Richard Maw 
wrote:

> On Mon, Nov 02, 2015 at 09:04:31AM +0100, Lennart Poettering wrote:
> > On Wed, 28.10.15 19:30, John (da_audioph...@yahoo.com) wrote:
> >
> > > I have a simple bash script that I would like to have a user service
> > > file run with an argument when the system enters a sleep or
> > > hibernation state but as I understand it, user service units do not
> > > use the sleep.target.  The goal is to have the following run before
> > > the system goes into sleep/hibernate triggered by whatever mechanism
> > > systemd uses to detect when the user sleeps or hibernates the
> > > system: '/usr/bin/psd sync'
> >
> > You can install a suspend delay inhibitor:
> >
> > https://wiki.freedesktop.org/www/Software/systemd/inhibit/
> >
> > That works from privileged code the same as for user code. However,
> > you cannot really do that from shell code. I fear for shell this is
> > simply not available, sorry.
>
> You may be able to abuse the hell out of systemd-inhibit to have it work:
>
> #!/bin/sh
> # Approach cribbed from http://www.opopop.net/Harnessing_DBus/


Might as well use ctypes.sh then... Or a more capable language:

https://gist.github.com/grawity/a10ee46d7ff58048d483

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Pulseaudio & systemd-nspawn

[Felipe Sateler]

On Mon, 02 Nov 2015 11:29:56 +0800, Kai Hendry wrote:

> Hi there,
> 
> I'm trying to have a super simple way of launching a browser in a VPN.
> 
> I am on Archlinux with systemd 227-1 with pulseaudio 7.1-1 & I have
> another Arch container configured like so:

Do you have the pulseaudio server installed in the container? I think you 
shouldn't, so that the client inside the container connects to the server 
in the host.

Otherwise, what you need it to make the pulseaudio server in the 
container talk to the server in the host, and for that you should not 
bind /dev/snd nor /run/user/1000/pulse

> 
> X1C3:~$ cat
> /etc/systemd/system/systemd-nspawn@firefox.service.d/override.conf
> [Service]
> ExecStart=
> ExecStart=/usr/bin/systemd-nspawn
> --bind-ro=/home/hendry/.Xauthority:/root/.Xauthority \
> --bind=/tmp/.X11-unix \
> --bind=/dev/snd \

I don't think this is appropriate. There should be no sound card on the 
container.

> --bind=/run/user/1000/pulse:/run/user/1000/pulse

Won't this get hidden by the tmpfs in /run/user ?

Maybe the better option is to load the tcp pulseaudio module, allow 
connections from the container ip, and inject PULSE_SERVER envvar into 
the container.



-- 
Saludos,
Felipe Sateler

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Keeping track of usage time

[Umut Tezduyar Lindskog]

Hi,

We would like to implement a feature to keep track of accumulated
values of uptimes in our products. Tracked time will give us the total
usage time of our product not just since last reboot (/proc/uptime).

Is upstream interested in having such implementation?

Umut
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Keeping track of usage time

[Dimitri John Ledkov]

On 2 November 2015 at 14:46, Umut Tezduyar Lindskog  wrote:
> Hi,
>
> We would like to implement a feature to keep track of accumulated
> values of uptimes in our products. Tracked time will give us the total
> usage time of our product not just since last reboot (/proc/uptime).
>
> Is upstream interested in having such implementation?
>

Isn't that just the duration of each bootid from journal then?

Checkout output of:

$ journalctl --list-boots

-- 
Regards,

Dimitri.
63 sleeps till Christmas, or less

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-nspawn and process spawning using nsenter issue

[Aliaksei Sheshka]

Hello!

I have some systemd-nspawn and namespace related question.
Assume following commands,

$ systemctl start c7-test #starring our container
$ systemctl status c7-test #checking if it is running and looking for
inside /usr/lib/systemd/systemd process
$ nsenter -t 22333 -n /usr/local/sbin/custom-network-daemon  #starting
our network daemon located on the host filesystem but withing
container network namespace

I have a strong reason doing so, let say one need to modify clock on
the host machine, while container provides very special routing table
- it is oversimplification, but somewhat my use case.

My questions are
a) Once container c7-test shut down using 'machinectl poweroff
c7-test' how one can know what some processes are still running
withing that network context?
My  /usr/local/sbin/custom-network-daemon is perfectly running after
c7-tets was shut down, which it obviously expected behavior.

b) Is there a generic method to list currently active namespaces?
machinectl does not show as expected, since it's a machine lister and
machine is not running.
'ip netns list' is not listing them either, if there any other utility
for that? If not is there a kernel interface to create one?

c) Since /usr/local/sbin/custom-network-daemon is still running
withing previously created by 'systemctl start c7-test' network
namespace, one can't start same container again properly -
while container starts, networking fails silently in case of
--network-macvlan=eth0, one just can't bring inside interface UP.
Should systemd-nspawn fail with error in such cases?

Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn and process spawning using nsenter issue

[Richard Maw]

On Mon, Nov 02, 2015 at 09:27:42AM -0500, Aliaksei Sheshka wrote:
> Hello!
> 
> I have some systemd-nspawn and namespace related question.
> Assume following commands,
> 
> $ systemctl start c7-test #starring our container
> $ systemctl status c7-test #checking if it is running and looking for
> inside /usr/lib/systemd/systemd process
> $ nsenter -t 22333 -n /usr/local/sbin/custom-network-daemon  #starting
> our network daemon located on the host filesystem but withing
> container network namespace
> 
> I have a strong reason doing so, let say one need to modify clock on
> the host machine, while container provides very special routing table
> - it is oversimplification, but somewhat my use case.
> 
> My questions are
> a) Once container c7-test shut down using 'machinectl poweroff
> c7-test' how one can know what some processes are still running
> withing that network context?
> My  /usr/local/sbin/custom-network-daemon is perfectly running after
> c7-tets was shut down, which it obviously expected behavior.
> 
> b) Is there a generic method to list currently active namespaces?
> machinectl does not show as expected, since it's a machine lister and
> machine is not running.
> 'ip netns list' is not listing them either,

This is because `ip netns add` and the rest
work by bind-mounting the network namespace to a file.

Systemd does not do this when creating network namespaces,
since then the namespaces can be bound to the lifetime of the processes,
and you don't need an explicit namespace cleanup step.

However since you entered the namespace manually,
and your process is not in the cgroup of the container,
your network daemon process is neither managed by the nspawn cgroup,
nor any systemd running in the container,
so as far as systemd is concerned, it successfully shut it down.

> is there any other utility
> for that? If not is there a kernel interface to create one?

I don't know of any utilities, but /proc/$pid/ns/net is a symlink pointing
to a magic file that refers to the network namespace.

You could have a tool enumerate all your processes and stat the symlinks,
though it's a privileged operation to view someone else's namespaces
so you'd have to run the following with sudo:

#!/usr/bin/python

from collections import defaultdict
from os import listdir, stat
from os.path import join

namespaces = defaultdict(set)

for fn in listdir('/proc'):
if all(c.isdigit() for c in fn):
pid = int(fn)
ino = stat(join('/proc', fn, 'ns', 'net')).st_ino
namespaces[ino].add(pid)

print("You have processes in %d namespaces" % len(namespaces))
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Keeping track of usage time

[Lennart Poettering]

On Mon, 02.11.15 15:46, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

> Hi,
> 
> We would like to implement a feature to keep track of accumulated
> values of uptimes in our products. Tracked time will give us the total
> usage time of our product not just since last reboot (/proc/uptime).
> 
> Is upstream interested in having such implementation?

As Dimitri suggested: wouldn't a journalctl --list-boots invocation
suffice for this?

Or do you need this per-service? (where the journal should be able to
provide you with the answer too, of course, but with a different line)

Lennart

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

Re: [systemd-devel] systemd-nspawn and process spawning using nsenter issue

[Lennart Poettering]

On Mon, 02.11.15 09:27, Aliaksei Sheshka (sheshka...@gmail.com) wrote:

> Hello!
> 
> I have some systemd-nspawn and namespace related question.
> Assume following commands,
> 
> $ systemctl start c7-test #starring our container
> $ systemctl status c7-test #checking if it is running and looking for
> inside /usr/lib/systemd/systemd process
> $ nsenter -t 22333 -n /usr/local/sbin/custom-network-daemon  #starting
> our network daemon located on the host filesystem but withing
> container network namespace
> 
> I have a strong reason doing so, let say one need to modify clock on
> the host machine, while container provides very special routing table
> - it is oversimplification, but somewhat my use case.
> 
> My questions are
> a) Once container c7-test shut down using 'machinectl poweroff
> c7-test' how one can know what some processes are still running
> withing that network context?

I am not aware of any way how you can enumerate namespaces on Linux,
or their members. Usually you combine them with cgroups or suchlike,
and you can enumerate those, but if you make them go away you have no
handle anymore.

As suggested by Richard, you can pin the namespace if you like via
bind mounts, but systemd won't do that for you, and enumeration still
isn't nice if you (you'd have to compare the ns files in /proc to
match up processes)

> My  /usr/local/sbin/custom-network-daemon is perfectly running after
> c7-tets was shut down, which it obviously expected behavior.
> 
> b) Is there a generic method to list currently active namespaces?
> machinectl does not show as expected, since it's a machine lister and
> machine is not running.
> 'ip netns list' is not listing them either, if there any other utility
> for that? If not is there a kernel interface to create one?

I am not aware of any. machined keeps tracks of machines, that's
really what it is about, but if you shut down the machine and just
keep the net namespace part of it alive, then of course, machined
won't know it. ip netns is based on pinning net namespaces via bind
mounts, but we don't do that with nspawn.

> c) Since /usr/local/sbin/custom-network-daemon is still running
> withing previously created by 'systemctl start c7-test' network
> namespace, one can't start same container again properly -
> while container starts, networking fails silently in case of
> --network-macvlan=eth0, one just can't bring inside interface UP.
> Should systemd-nspawn fail with error in such cases?

Hmm, of course, this should really generate an error and fail... 

BTW: another way to deal with network namespaces in systemd is via
PrivateNetwork=yes and JoinsNamespaceOf=, but I am not whether that
matches what you want to do...

Lennart

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

Re: [systemd-devel] journalctl's http://localhost:19531/browse

[Lennart Poettering]

On Mon, 02.11.15 18:44, Kai Hendry (hen...@webconverger.com) wrote:

> On Mon, 2 Nov 2015, at 06:10 PM, Lennart Poettering wrote:
> > Note that the website will show only those accessible to the
> > "systemd-journal" group.
> > 
> > Did you run "logger" unprivileged? Did you run journalctl privileged?
> > That might explain the difference?
> 
> In that video earlier I ran journalctl as my user, so unprivileged, but
> it still sees my logger commands, unlike http://localhost:19531/browse
> 
> Though what you said sounds like a good explanation. However how do make
> the Web interface show my user's `logger` invocations? I did try adding
> my user to the systemd-journal group, but that didn't seem to solve my
> issue.

Hmm, maybe there's something wrong with the ACLs on the journal files
or the directory they reside in? Normally, there should be an ACL that
allows the "systemd-journal" group access to all files, and
systemd-journal-gatewayd is running with that group among its
auxiliary group ids...

> > well, systemd-journal-gatewayd serves that already, you can just use
> > that...
> 
> Ah! Perfect. Oh but I need a way to setup CORS so I can access it from
> my Webapp:
> http://s.natalian.org/2015-11-02/systemd-journal-gatewayd.png

CORS? I don't know what that means?

> Shall I file a bug?
> https://github.com/systemd/systemd/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+systemd-journal-gatewayd

Regarding what precisely?

Lennart

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

[systemd-devel] Run cleanup service on stop

[Kai Hendry]

Hi there guys,

I have a service where it's important that it cleans up *after* it's
run. In fact it's probably a good idea to make sure it's clean *before*
it's run too.

I got as far as:

After=clean.service
Requires=clean.service

But that does not seem to clean on stop (say if the machine is shutting
down). What am I missing?

My alternative approach which seems to work is to use:

ExecStartPre=...
ExecStopPost=...

But it looks a little ugly. Here is my source:
http://s.natalian.org/2015-11-03/service-or-exec.tar

Be great to review/critique and suggestions for improvement. I would
like to get $HOME onto a private tmpfs going into the future, though I
am not sure how to achieve that with systemd. Are there any similar
examples I could study?

Many thanks,
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn and process spawning using nsenter issue

[Aliaksei Sheshka]

On Mon, Nov 2, 2015 at 1:05 PM, Lennart Poettering
 wrote:


>
> BTW: another way to deal with network namespaces in systemd is via
> PrivateNetwork=yes and JoinsNamespaceOf=, but I am not whether that
> matches what you want to do...

Perhaps, I've tried

[Unit]
Description=mydaemon withing c7-test network context
After=network.target

[Service]
TimeoutStartSec=10
ExecStart=/usr/sbin/mydaemon
JoinsNamespaceOf=c7-test.service
PrivateTmp=yes
PrivateNetwork=yes

[Install]
WantedBy=multi-user.target


but looks likes it creates new namespace, because 'mydaemon' sees only
127.0.0.1 with such unit.
c7-test unit is 100% running.
Another question, would 'machinectl poweroff c7-test' terminate
[properly configured] 'mydaemon' unit as well ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Keeping track of usage time

[Umut Tezduyar Lindskog]

journalctl --list-boots seems great actually but wouldn't work for us.
We cannot keep lots of logs in our products.

Ultimately we are trying to answer the question of how long one of our
product has been in use.

We will implement it with a .timer/.service which periodically adds
/proc/uptime to a file and the file gets preserved over reboot.

Umut

On Mon, Nov 2, 2015 at 7:00 PM, Lennart Poettering
 wrote:
> On Mon, 02.11.15 15:46, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
>
>> Hi,
>>
>> We would like to implement a feature to keep track of accumulated
>> values of uptimes in our products. Tracked time will give us the total
>> usage time of our product not just since last reboot (/proc/uptime).
>>
>> Is upstream interested in having such implementation?
>
> As Dimitri suggested: wouldn't a journalctl --list-boots invocation
> suffice for this?
>
> Or do you need this per-service? (where the journal should be able to
> provide you with the answer too, of course, but with a different line)
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journalctl's http://localhost:19531/browse

[Kai Hendry]

On Tue, 3 Nov 2015, at 02:27 AM, Lennart Poettering wrote:
> Hmm, maybe there's something wrong with the ACLs on the journal files
> or the directory they reside in? Normally, there should be an ACL that
> allows the "systemd-journal" group access to all files, and
> systemd-journal-gatewayd is running with that group among its
> auxiliary group ids...

Still at a loss to resolve this. How I loathe unix permissions. I'd
rather run systemd-journal-gatewayd as my user instead systemd+ as it's
running now to avoid this time wasting exercise.

> CORS? I don't know what that means?

It's a Web server header that permits what Web apps can interact with
it.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

So a possible API would be:

/usr/lib/systemd/systemd-journal-gatewayd
--header="Access-Control-Allow-Origin: *"

Which would be seen in the output of `curl -I
'http://localhost:19531/entries?boot'`, and the * would allow any Web
app no matter where it's hosted to get log events IIUC. So not a good
default but could be useful. :)

Cheers,
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journalctl's http://localhost:19531/browse

[Kai Hendry]

On Mon, 2 Nov 2015, at 07:58 PM, Colin Guthrie wrote:
> I suspect that you'd probably want to hide this behind some kind of
> proxy for security reasons. That proxy could add appropriate
> authentication (e.g IP restrictions, user auth etc) and add in any
> additional headers).
> I could be wrong with this suggestion, but this would be my first guess
> at how you would solve this problem.

You are correct it could be solved by a proxy. A lot of bad APIs can be
solved with a proxy. But you must concede that it is an awful
obstacle/dependency to getting things done. ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help writing a user service file that will exec a command upon system sleep

[Lennart Poettering]

On Wed, 28.10.15 19:30, John (da_audioph...@yahoo.com) wrote:

> I have a simple bash script that I would like to have a user service
> file run with an argument when the system enters a sleep or
> hibernation state but as I understand it, user service units do not
> use the sleep.target.  The goal is to have the following run before
> the system goes into sleep/hibernate triggered by whatever mechanism
> systemd uses to detect when the user sleeps or hibernates the
> system: '/usr/bin/psd sync'

You can install a suspend delay inhibitor:

https://wiki.freedesktop.org/www/Software/systemd/inhibit/

That works from privileged code the same as for user code. However,
you cannot really do that from shell code. I fear for shell this is
simply not available, sorry.

Lennart

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

Re: [systemd-devel] Delete stale *.journal-files from containers

[Lennart Poettering]

On Wed, 28.10.15 14:39, Peter Paule (systemd-de...@fedux.org) wrote:

> 
> Hi,
> 
> I use `docker` to run containers. Each container uses `systemd` as PID 1. I
> pass `-v /var/log/journal:/var/log/journal` to `docker run` to accumulate
> journals on the docker host. Every time a container is started, a new
> journal file is generated based on the machine-id, leaving quite a few
> 8MiB-`system.journal`-files on the system after the container was "stopped".
> 
> Example:
> 
> ~~~
> docker run --name centos-1 --rm -ti -v /sys/fs/cgroup:/sys/fs/cgroup -v
> /var/log/journal:/var/log/journal feduxorg/centos
> ~~~
> 
> Is there way beside `find /var/log/journal -time +30 -delete` to get rid of
> stale old `journal`.files? I tried `MaxRetentionSec=1day` and
> `MaxTimeSec=1day`, but none of this made `systemd-journald` to delete the
> `system.journal`-files.

Normally, if a system gets shutdown correctly the existing journal
file should be reused on the next startup again. A new file is only
created if the system wasn't shut down correctly and the old file is
found to be in a "dirty" state.

That said, if the machine ID changes on each boot a new directory will
be created too. 

The main "system.journal" file is where systemd writes its stuff to,
so it is obviously not removed by vacuuming.

Also note that "journalctl --vacuum-size=", "journalctl
--vacuum-files=", journalctl --vacuum-time=" may be used to vacuum the
files out-of-band.

Lennart

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

Re: [systemd-devel] journalctl's http://localhost:19531/browse

[Lennart Poettering]

On Mon, 02.11.15 13:05, Kai Hendry (hen...@webconverger.com) wrote:

> Hi guys,
> 
> Just playing around with the journalctl Web interface here:
> http://s.natalian.org/2015-11-02/journalctl.mp4
> 
> How come messages like `logger foo` do not appear in
> http://localhost:19531/browse but they do in `journalctl -b -f`?

Note that the website will show only those accessible to the
"systemd-journal" group.

Did you run "logger" unprivileged? Did you run journalctl privileged?
That might explain the difference?

> Is the API for http://localhost:19531/ defined somewhere since I
> wouldn't mind creating my own Web interface with the JSON. Ideally the
> server could support text/event-stream like I demonstrate here:
> https://www.youtube.com/watch?v=XmCDji3t7eg

It's not really documented, but it should be... it's fairly easy
though, and the default web page should explain most of it...

> I did notice `journalctl -o json-sse`, but you need a server to hand
> those off to the browser. How should that be done with libmicrohttpd ??

well, systemd-journal-gatewayd serves that already, you can just use that...

Lennart

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

Re: [systemd-devel] systemd-nspawn and process spawning using nsenter issue

[Lennart Poettering]

On Mon, 02.11.15 14:52, Aliaksei Sheshka (sheshka...@gmail.com) wrote:

> On Mon, Nov 2, 2015 at 1:05 PM, Lennart Poettering
>  wrote:
> 
> 
> >
> > BTW: another way to deal with network namespaces in systemd is via
> > PrivateNetwork=yes and JoinsNamespaceOf=, but I am not whether that
> > matches what you want to do...
> 
> Perhaps, I've tried
> 
> [Unit]
> Description=mydaemon withing c7-test network context
> After=network.target
> 
> [Service]
> TimeoutStartSec=10
> ExecStart=/usr/sbin/mydaemon
> JoinsNamespaceOf=c7-test.service
> PrivateTmp=yes
> PrivateNetwork=yes
> 
> [Install]
> WantedBy=multi-user.target
> 
> 
> but looks likes it creates new namespace, because 'mydaemon' sees only
> 127.0.0.1 with such unit.
> c7-test unit is 100% running.
> Another question, would 'machinectl poweroff c7-test' terminate
> [properly configured] 'mydaemon' unit as well ?

Note that all units you join need to have PrivateNetwork=yes set if
they shall live in the same namespace. Did both your units have this set?

Lennart

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

Re: [systemd-devel] journalctl's http://localhost:19531/browse

[Kai Hendry]

On Mon, 2 Nov 2015, at 06:10 PM, Lennart Poettering wrote:
> Note that the website will show only those accessible to the
> "systemd-journal" group.
> 
> Did you run "logger" unprivileged? Did you run journalctl privileged?
> That might explain the difference?

In that video earlier I ran journalctl as my user, so unprivileged, but
it still sees my logger commands, unlike http://localhost:19531/browse

Though what you said sounds like a good explanation. However how do make
the Web interface show my user's `logger` invocations? I did try adding
my user to the systemd-journal group, but that didn't seem to solve my
issue.

> well, systemd-journal-gatewayd serves that already, you can just use
> that...

Ah! Perfect. Oh but I need a way to setup CORS so I can access it from
my Webapp:
http://s.natalian.org/2015-11-02/systemd-journal-gatewayd.png

Shall I file a bug?
https://github.com/systemd/systemd/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+systemd-journal-gatewayd

Kind regards,
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journalctl's http://localhost:19531/browse

[Colin Guthrie]

Kai Hendry wrote on 02/11/15 10:44:
>> > well, systemd-journal-gatewayd serves that already, you can just use
>> > that...
> Ah! Perfect. Oh but I need a way to setup CORS so I can access it from
> my Webapp:
> http://s.natalian.org/2015-11-02/systemd-journal-gatewayd.png
> 
> Shall I file a bug?

I suspect that you'd probably want to hide this behind some kind of
proxy for security reasons. That proxy could add appropriate
authentication (e.g IP restrictions, user auth etc) and add in any
additional headers).

I could be wrong with this suggestion, but this would be my first guess
at how you would solve this problem.

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn and process spawning using nsenter issue

[Aliaksei Sheshka]

>
> Note that all units you join need to have PrivateNetwork=yes set if
> they shall live in the same namespace. Did both your units have this set?

I have my unit c7-test like that:

ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot
--link-journal=try-guest --network-macvlan=eth0 --settings=override
--machine=c7-test

--networ-macvlan assumes  PrivateNetwork as I understand.
If I add additional  "PrivateNetwork=yes" to that nspawn unit, it
won't work, since, obviously, eth0 is no longer available.

In short my goal to have macvlan enabled systemd-nspawn container
running. Once it's up, I would like to run a daemon withing that
container ip namespace using binary located on the host system.
Current 'nsenter' solution looks not that elegant.  Perhaps there is a
better way to achieve that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help writing a user service file that will exec a command upon system sleep

[Richard Maw]

On Mon, Nov 02, 2015 at 04:11:14PM +0200, Mantas Mikulėnas wrote:
> On Mon, Nov 2, 2015 at 3:34 PM, Richard Maw 
> wrote:
> 
> > On Mon, Nov 02, 2015 at 09:04:31AM +0100, Lennart Poettering wrote:
> > > On Wed, 28.10.15 19:30, John (da_audioph...@yahoo.com) wrote:
> > >
> > > > I have a simple bash script that I would like to have a user service
> > > > file run with an argument when the system enters a sleep or
> > > > hibernation state but as I understand it, user service units do not
> > > > use the sleep.target.  The goal is to have the following run before
> > > > the system goes into sleep/hibernate triggered by whatever mechanism
> > > > systemd uses to detect when the user sleeps or hibernates the
> > > > system: '/usr/bin/psd sync'
> > >
> > > You can install a suspend delay inhibitor:
> > >
> > > https://wiki.freedesktop.org/www/Software/systemd/inhibit/
> > >
> > > That works from privileged code the same as for user code. However,
> > > you cannot really do that from shell code. I fear for shell this is
> > > simply not available, sorry.
> >
> > You may be able to abuse the hell out of systemd-inhibit to have it work:
> >
> > #!/bin/sh
> > # Approach cribbed from http://www.opopop.net/Harnessing_DBus/
> 
> 
> Might as well use ctypes.sh then...

Heh, certainly. I'd forgotten that existed.

I mostly took the suggestion that it wasn't possible from shell as a challenge 
:-)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel