Re: [systemd-devel] systemd user service when x is started
From arnaud gaboury, Fri 07 Nov 2014 at 21:00:14 (+0100) : I maybe was not explicit enough. I have a bunch of user services started as soon as I log in. then I $ startx After this command, I would like systemctl --user start some services (window manager, etc). Yes, this is the same setup I use. The first bunch of services are grouped under the console.target. Now I am looking for a way to group GUI services in something like graphical.target (or whatever else name). As I said, you just need to ensure that when you startx, your session launch 'systemctl --user wm.target' automatically. I put this command in my '.xprofile' (because the *DM usually source this file), and my .xinitrc contains [ -r $HOME/.xprofile ] . $HOME/.xprofile so it works with startx too. -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] network/networkd-netdev-veth.c: Fix a typo.
This patch fixes a typo in network/networkd-netdev-veth.c.
Signed-off-by: Rami Rosen ramir...@gmail.com
---
src/network/networkd-netdev-veth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/network/networkd-netdev-veth.c
b/src/network/networkd-netdev-veth.c
index da09ef9..ca2bb07 100644
--- a/src/network/networkd-netdev-veth.c
+++ b/src/network/networkd-netdev-veth.c
@@ -39,7 +39,7 @@ static int netdev_veth_fill_message_create(NetDev *netdev,
Link *link, sd_rtnl_m
r = sd_rtnl_message_open_container(m, VETH_INFO_PEER);
if (r 0) {
log_error_netdev(netdev,
- Could not append IFLA_IPTUN_LINK attribute:
%s,
+ Could not append VETH_INFO_PEER attribute:
%s,
strerror(-r));
return r;
}
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] network/networkd-netdev-veth.c: Fix a typo.
Hi
On Sat, Nov 8, 2014 at 11:59 AM, Rami Rosen ramir...@gmail.com wrote:
This patch fixes a typo in network/networkd-netdev-veth.c.
Signed-off-by: Rami Rosen ramir...@gmail.com
No sign-offs needed on systemd.
I changed the commit-msg to systemd style and pushed the fix as
network: fix typo.
Thanks!
David
---
src/network/networkd-netdev-veth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/network/networkd-netdev-veth.c
b/src/network/networkd-netdev-veth.c
index da09ef9..ca2bb07 100644
--- a/src/network/networkd-netdev-veth.c
+++ b/src/network/networkd-netdev-veth.c
@@ -39,7 +39,7 @@ static int netdev_veth_fill_message_create(NetDev *netdev,
Link *link, sd_rtnl_m
r = sd_rtnl_message_open_container(m, VETH_INFO_PEER);
if (r 0) {
log_error_netdev(netdev,
- Could not append IFLA_IPTUN_LINK
attribute: %s,
+ Could not append VETH_INFO_PEER attribute:
%s,
strerror(-r));
return r;
}
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user service when x is started
As I said, you just need to ensure that when you startx, your session launch 'systemctl --user wm.target' automatically. I put this command in my '.xprofile' (because the *DM usually source this file), and my .xinitrc contains [ -r $HOME/.xprofile ] . $HOME/.xprofile so it works with startx too. very good indeed. Like a bozo, I was not aware of this ~/.xprofile. Just for other users, the correct command to include is: 'systemctl --user start wm.target Thank you for your help, and drink a Bordeaux glass for me. -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unexpecte behavior for timer with OnActiveSec
В Fri, 7 Nov 2014 08:56:49 + Paassen, Hiram van hiram.van.paas...@mastervolt.com пишет: Hi, We need to switch to a different target after 30 min of starting that target. Switching happens with isolate. So we have a timer with OnActiveSec=30min witch starts a service that calls systemctl isolate other.target This works like a charm... the first time the target is activated. The second time we start that target nothing happens after 30 min. After some manual testing I can conclude that a timer with OnActiveSec set will stay in elapsed state even after the timer has been restarted or stopped and then started. This is not what I expect. Also there seems to be no way to reset it to the waiting/running state except for the following procedure: systemctl daemon-reload systemctl restart timer.timer Is this expected behavior or a bug? It is not a bug as far as I can tell; but timer state should be reset when unit it triggered changes state. So you have A.target that calls B.timer that triggers B.target. Next time A.target tries to start B.timer - is B.target still active? P.S. actually the fact that you can restart timer after daemon-reload is probably a bug :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unexpecte behavior for timer with OnActiveSec
On Sat, Nov 08, 2014 at 04:36:30PM +0300, Andrei Borzenkov wrote: В Fri, 7 Nov 2014 08:56:49 + Paassen, Hiram van hiram.van.paas...@mastervolt.com пишет: Hi, We need to switch to a different target after 30 min of starting that target. Switching happens with isolate. So we have a timer with OnActiveSec=30min witch starts a service that calls systemctl isolate other.target This works like a charm... the first time the target is activated. The second time we start that target nothing happens after 30 min. After some manual testing I can conclude that a timer with OnActiveSec set will stay in elapsed state even after the timer has been restarted or stopped and then started. This is not what I expect. Also there seems to be no way to reset it to the waiting/running state except for the following procedure: systemctl daemon-reload systemctl restart timer.timer Is this expected behavior or a bug? It is not a bug as far as I can tell; but timer state should be reset when unit it triggered changes state. So you have A.target that calls B.timer that triggers B.target. Next time A.target tries to start B.timer - is B.target still active? P.S. actually the fact that you can restart timer after daemon-reload is probably a bug :) http://cgit.freedesktop.org/systemd/systemd/commit/?id=779042e772 might be related. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown problems
Lennart Poettering lenn...@poettering.net writes: On Thu, 06.11.14 19:07, Nikolaus Rath (nikol...@rath.org) wrote: Hello, I'm having some trouble shutting down my system with systemd. What happens is the following: * If I execute systemctl reboot while a text console is active, everything works fine. * If I execute systemctl reboot while the X11 console is active, the system hangs (I tried waiting up to 7 minutes). Furthermore, I am unable to switch to another console with Ctrl+Alt+Fn, the computer becomes unresponsive to the keyboard and the monitor powers down. On which tty/pty systemctl itself is executed does not matter (I tested this by running systemctl in an ssh session from a remote system), it only matters which console is currently active. I tried the debugging technique from http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 and created a file debug.sh in /lib/systemd/system-shutdown with permisson 755 and the following contents: $ cat /lib/systemd/system-shutdown/debug.sh #!/bin/sh exec /shutdown.log exec 21 mount -o remount,rw / echo stdout echo stderr 2 dmesg systemctl list-jobs systemctl status echo done mount -o remount,ro / You open the file for writing before you actually mount the fs read-only. That cannot work. However, no file /shutdown.log is created after reboot. I also tried placing debug.sh in /usr/lib/systemd/system-shutdown instead (this is a Debian system), but this did not work either. I also tried enabling the debug-shell, but this did not help because I can't access tty9 when the hang occurs. I also tried running an sshd process in the debug shell (to see if I can still reach the system remotely when it hangs), but the connection got closed when I ran the systemctl command - why might that be? I had hoped that processes spawned from the debug-shell would not get killed? I am using systemd 215-5+b1 on Debian jessie. I also have plymouth enabled. Anyone able to help? Please boot with systemd.log_level=debug, then make the machine hang and check what the last things in the logs say. Maybe then paste that somewhere online and post the URL for that here, so that we can have a look. Here's the output (obtained by changing log level and remounting earlier in the debug.sh script): https://dl.dropboxusercontent.com/u/11545826/shutdown.log Thanks for your help! Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option
On 11/6/2014 10:43 PM, WaLyong Cho wrote:
On 11/07/2014 09:35 AM, Lennart Poettering wrote:
On Fri, 07.11.14 04:17, WaLyong Cho (walyong@gmail.com) wrote:
SMACK64
Used to make access control decisions. In almost all cases
the label given to a new filesystem object will be the label
of the process that created it.
SMACK64EXEC
The Smack label of a process that execs a program file with
this attribute set will run with this attribute's value.
I am sorry, but I cannot parse this.
The smack label will run with this attribute's value? smack
labels run? That sentence makes no sense to me at all...
Again, what kind of objects are SMACK64 and SMACK64EXEC applied to?
files? processes?
Sorry, I'm also confused.
OK, I asked some about this to my security friend.
And I add Casey Schaufler who the Author of smack.
I hope my below explain it not wrong. But if not, please point out.
Quoting the Wikipedia:
In practice, a subject is usually a process or thread; objects are
constructs such as files, directories, TCP/UDP ports, shared memory
segments, IO devices etc.
In case of SMACK, subject is SMACK64EXEC and object is SMACK64.
The SMACK64 attribute of any object (file, directory, IPC object, ...)
is used in access control decisions on that object.
The SMACK64EXEC attribute is very much like the setuid bit on an executable.
If the attribute is set (and it should almost *never* be set) on a program file
the process execing the program will change its Smack label to the value in
the SMACK64EXEC attribute.
On execution:
The existing process Smack label must allow eXec access to the program file,
based on the Smack label of the process and the SMACK64 attribute of the
program file. If there is no SMACK64EXEC attribute on the file the Smack label
of the process is unchanged. If there is a SMACK64EXEC attribute the Smack label
of the process changes to that value.
Note that the SMACK64 attribute is present on all files and has no impact on
the Smack label of the process. The SMACK63EXEC attribute is optional. Most
program files do not have this attribute. It should be only used in cases where
the Smack label of the program must always be a particular value.
Thus, dbus is a fine example where SMACK64EXEC is a bad idea. Because you
want a system bus and a user bus with different attributes you want it to get
the Smack label at launch time, just like you do for UID and capability sets.
Assume like this: /usr/bin/dbus-daemon has both label. SMACK64 is foo
and SMACK64EXEC is bar. And current process (what will execute the
/usr/bin/dbus-daemon) has foo label. Let's assume the current process
is sh. Then /proc/$$/attr/current of sh is foo. There is no problems
to sh execute the /usr/bin/dbus-daemon because the sh has same label
with /usr/bin/dbus-daemon. Now /usr/bin/dbus-daemon will be executed by
sh. But it has SMACK64EXEC label bar. So executed attr/current of
/usr/bin/dbus-daemon is bar.
If the sh has label waldo, then maybe two case can be existed. If
label waldo has executable rule for label foo then the sh can
execute the /usr/bin/dbus-daemon. But if label waldo has no rule for
that, then sh can not execute the /usr/bin/dbus-daemon. EACCESS will be
occurred. If label waldo has executable rule for label foo and
/usr/bin/dbus-daemon was executed. Then the executed dbus-daemon process
has attribute bar at /proc/{pid of dbus-daemon}/attr/current.
# attr -l /bin/sleep
Attribute SMACK64 has a 4 byte value for /bin/sleep
Attribute SMACK64EXEC has a 3 byte value for /bin/sleep
# attr -S -g SMACK64 /bin/sleep
Attribute SMACK64 had a 4 byte value for /bin/sleep:
foo
# attr -S -g SMACK64EXEC /bin/sleep
Attribute SMACK64EXEC had a 3 byte value for /bin/sleep:
bar
# cat /proc/$$/attr/current
waldo
# /bin/sleep 100
[1] 15263
sh-3.2# cat /proc/15263/attr/current
bar
Additionally, SMACK64EXEC can be none. Then the executed process inherit
attribute from the caller process. So sh has attribute waldo and
/bin/sleep has only SMACK64 foo then the executed /bin/sleep process
has waldo attribute.
# cat /proc/$$/attr/current
waldo
# attr -l /bin/sleep
Attribute SMACK64 has a 4 byte value for /bin/sleep
# attr -S -g SMACK64 /bin/sleep
Attribute SMACK64 had a 4 byte value for /bin/sleep:
foo
# /bin/sleep 100
[1] 4509
# cat /proc/4509/attr/current
waldo
Back to the systemd execute problem with User= option. Exclude Netlabel,
the access checking is ignored for all root uid processes. So there is
no problems to execute the ExecStart= without User= option.
But if a service has User= option and executable binary on ExecStart=
has label foo then the fork()-ed systemd child process has no root
uid. And the child systemd process has _ label.(see below predefined
labels.) If _ has no executable rule for foo then access deny will
be occurred. So to successfully execute the ExecStart=, the child
systemd process have to has attribute
Re: [systemd-devel] [RFC 4/4] add remote-fs dependencies if needed after change
В Thu, 6 Nov 2014 21:11:03 -0800
Chris Leech cle...@redhat.com пишет:
This is an attempt to add it the remote-fs dependencies to a mount unit
if the options change, like when the utab options are picked up after
mountinfo has already been processed. It just adds the remote-fs
dependencies, leaving the local-fs ones in place.
With this change I always get mount units with proper remote-fs
dependencies when mounted with the _netdev option.
It it not working for -o remount,_netdev. But that looks like a
libmount issue in that the ROOT field is not being set in utab on a
remount, so if the initial mount did not require a utab entry then
remount options never get merge in properly in mnt_table_parse_mtab
---
src/core/mount.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/core/mount.c b/src/core/mount.c
index 7d77021..092a720 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1436,6 +1436,19 @@ static int mount_add_one(
}
}
+if (m-running_as == SYSTEMD_SYSTEM) {
+const char* target;
+
+target = mount_needs_network(options, fstype) ?
SPECIAL_REMOTE_FS_TARGET : NULL;
+/* _netdev option may have shown up late, or on a
+ * remount. Add remote-fs dependencies, even though
+ * local-fs ones may already be there */
+if (target) {
+unit_add_dependency_by_name(u, UNIT_BEFORE,
target, NULL, true);
Should not it also add After on network.target to ensure it is
unmounted before network is down on shutdown? May be simply calling
mount_add_default_dependencies() would be appropriate here.
+load_extras = true;
+}
+}
+
if (u-load_state == UNIT_NOT_FOUND) {
u-load_state = UNIT_LOADED;
u-load_error = 0;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
