Re: [systemd-devel] Writing a udev rule for U2F security tokens?
On Mon, Oct 27, 2014 at 04:37:14PM -0700, Andy Lutomirski wrote:
On Mon, Oct 27, 2014 at 4:32 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Oct 27, 2014 at 04:12:30PM -0700, Andy Lutomirski wrote:
Hi-
I'd like to write a generic udev rule for U2F security tokens and to
possibly get it integrated into systemd / udev, but I'm not sure how
to write it in the first place.
U2F tokens are USB HID devices that have a usage page 0xF1D0 that
contains usage 0x01. The rule should match any hidraw device with
that property. Can this be done without a user helper? Is there an
existing helper in which it would make sense to add such a check?
Here's the draft USB forum allocation:
http://www.usb.org/developers/hidpage/HUTRR48.pdf
Here's the draft spec from the FIDO Alliance:
https://fidoalliance.org/specs/fido-u2f-HID-protocol-v1.0-rd-20141008.pdf
In practice, I expect little change between the draft and final specs,
since these devices are already for sale and Chromium supports them.
I don't understand, what would a udev rule do with these devices?
Shouldn't they be exported automatically using the hid raw interface
so that userspace can talk to them? What else needs to be done?
Wow, I clearly failed to transfer my thoughts into email...
I want to set ID_SECURITY_TOKEN=1 or, more generally, cause the
uaccess tag to be set so that users have permission to use the token.
This rule works in Fedora for the existing tokens by Yubico:
KERNEL==hidraw*, SUBSYSTEM==hidraw, ATTRS{idVendor}==1050,
ATTRS{idProduct}==0113|0114|0115|0116|0120,
ENV{ID_SECURITY_TOKEN}=1
but it won't work for other brands of U2F token.
If there's no sysfs attribute that you can read directly to determine
that it is a a U2F token, then it's not easy to write a udev rule.
You can write a simple program to read the hid pages from the hidraw
interface, and then set an environment variable from there if the FIDO
Alliance Page is present. You can use a udev rule for that, but it
will have to be an external tool.
hope this helps,
greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v5] udev hwdb: Support shipping pre-compiled database in system images
Hello Lennart,
Lennart Poettering [2014-10-27 16:09 +0100]:
+static const char hwdb_bin_paths[] =
+/etc/udev/hwdb.bin\0
+UDEVLIBEXECDIR /hwdb.bin\0;
+
+
+static int open_hwdb_bin(const char **path, FILE** f) {
+const char* p;
+
+NULSTR_FOREACH(p, hwdb_bin_paths) {
+*path = p;
Please do not write functions that clobber passed-in arguments on
failure. Please store any result in a temporary variable first, and
clobber the passed-in variables only on success.
+*f = fopen(p, re);
same here.
Done for the FILE*, but I kept the behaviour for the path as the
caller uses the path in the error message on failure. I added a
comment to clarify this.
-if (stat(/etc/udev/hwdb.bin, st) 0)
+
+/* if hwdb.bin doesn't exist anywhere, we need to update */
+NULSTR_FOREACH(p, hwdb_bin_paths) {
+if (stat(p, st) = 0) {
+found = true;
+break;
+}
+}
+if (!found)
return true;
I'd prefer if you could use access(..., F_OK) here, for checking for
file existance, as stat() does substantially more than just checking
existance.
I'm aware of access(), but the code below actually uses the stat value
for timestamp comparison, so we really need stat() here.
I also changed the hwdb option to --usr now. It's not very
descriptive and wrong for /lib, but then again this is only really
being used in package maintainer scripts or custom system image
builds; users will hardly ever see this.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From e0feeb5eb9de066e6908d34dff47380e3e860d09 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Fri, 17 Oct 2014 15:01:01 +0200
Subject: [PATCH] udev hwdb: Support shipping pre-compiled database in system
images
In some cases it is preferable to ship system images with a pre-generated
binary hwdb database, to avoid having to build it at runtime, avoid shipping
the source hwdb files, or avoid storing large binary files in /etc.
So if hwdb.bin does not exist in /etc/udev/, fall back to looking for it in
UDEVLIBEXECDIR. This keeps the possibility to add files to /etc/udev/hwdb.d/
and re-generating the database which trumps the one in /usr/lib.
Add a new --usr flag to udevadm hwdb --update which puts the database
into UDEVLIBEXECDIR.
Adjust systemd-udev-hwdb-update.service to not generate the file in /etc if we
already have it in /usr.
---
man/udev.xml | 4 ++-
man/udevadm.xml | 9 ++
src/libudev/libudev-hwdb.c| 50 ++-
src/udev/udevadm-hwdb.c | 13 +++-
units/systemd-udev-hwdb-update.service.in | 3 ++
5 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/man/udev.xml b/man/udev.xml
index d77cbb0..87c16c7 100644
--- a/man/udev.xml
+++ b/man/udev.xml
@@ -766,7 +766,9 @@
paraThe content of all hwdb files is read by
citerefentryrefentrytitleudevadm/refentrytitlemanvolnum8/manvolnum/citerefentry
- and compiled to a binary database located at filename/etc/udev/hwdb.bin/filename.
+ and compiled to a binary database located at filename/etc/udev/hwdb.bin/filename,
+ or alternatively filename/usr/lib/udev/hwdb.bin/filename if you want ship the compiled
+ database in an immutable image.
During runtime only the binary database is used./para
/refsect1
diff --git a/man/udevadm.xml b/man/udevadm.xml
index 749144d..b85d9a9 100644
--- a/man/udevadm.xml
+++ b/man/udevadm.xml
@@ -494,6 +494,15 @@
/listitem
/varlistentry
varlistentry
+ termoption--usr/option/term
+ listitem
+paraPut the compiled database into filename/usr/lib/udev/hwdb.bin/filename instead.
+Use this if you want to ship a pre-compiled database in immutable system images, or
+don't use filename/etc/udev/hwdb.d/filename and want to avoid large binary files in
+filename/etc/filename./para
+ /listitem
+/varlistentry
+varlistentry
termoption-t/option/term
termoption--test=replaceablestring/replaceable/option/term
listitem
diff --git a/src/libudev/libudev-hwdb.c b/src/libudev/libudev-hwdb.c
index 8fb7240..1089645 100644
--- a/src/libudev/libudev-hwdb.c
+++ b/src/libudev/libudev-hwdb.c
@@ -256,6 +256,29 @@ static int trie_search_f(struct udev_hwdb *hwdb, const char *search) {
return 0;
}
+static const char hwdb_bin_paths[] =
+/etc/udev/hwdb.bin\0
+UDEVLIBEXECDIR /hwdb.bin\0;
+
+
+/* path is also written to on failures, so you can use it in error messages */
+static int open_hwdb_bin(const char **path, FILE** file) {
+const char* p;
+
Re: [systemd-devel] [PATCH 3/4] manager: stop start timeout when sysinit.target is reached
On Tue, 28.10.14 03:52, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Oct 28, 2014 at 02:32:37AM +0100, Lennart Poettering wrote: On Mon, 27.10.14 23:07, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 27.10.14 20:03, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Oct 27, 2014 at 06:51:08PM +0100, Lennart Poettering wrote: On Sat, 25.10.14 21:43, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: +if (result == JOB_DONE unit_has_name(u, SPECIAL_SYSINIT_TARGET)) +manager_cancel_start_timeout(u-manager); + I'd really prefer to hook this up with manager_state(), so that we don't have to hardcode the target name more than once, and so that we know that the rescue/emergency mode is properly handled... Yeah, I thought about that too, but only after I sent the patch. I'l look into hacking this up now, I really want to get the release out of the door now. I hacked this up now. Though after thinking forth and back quite differently than what we had before. I now removed the system-wide timeout, in favour of beefing up the existing JobTimeoutSec= stuff we have in units, so that we can set per-unit timeouts that trigger failure actions. With this in place I have now set default timeouts of 15min on basic.target and 30min on poweroff.target+reboot.target. Good, that sounds more flexible (and simpler). I'll push the change to avoid clobbering of password prompts. Hmm, did you see my comments about using BSD file locks for locking access to /dev/console, instead of explict checks for the ask-passwor stuff? http://lists.freedesktop.org/archives/systemd-devel/2014-October/024582.html I'll also add additional console prints before each failure action, so that people have a chance of knowing why their machine suddently turned off. Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd presentation slides?
Hi all, I've been assigned the task to introduce systemd to my sysadmin collegues, as it will be adopted by CentOS and Debian nextcoming releases. Debian+CentOS is 90% of our machines, the remaining 10% is negligeable. Would you have some bookmarks of some slide presenting systemd? Espacially what are the principal changes in our life, what to do if there is the need to package a daemon and there is only a SysV init script available, how to use the advanced diagnostic tool of systemd (if any), if running Debian what about update-rc.d and invoke-rc.d? If running CentOS what about chkconfig,... Sidenote: Our servers are all without X. Thanks for your inputs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] run: introduce timer support option
On Tue, 28.10.14 12:09, WaLyong Cho (walyong@samsung.com) wrote: The AccuracySec= and WakeSystem= stuff I think we don't need to cover with a command line argument of its own, we can cover that with --property=. Rework is almost done. Now I'm testing. But the AccuracySec= and WakeSystem= options are hard to deal with --property= option. Currently the --property= option of systemd-run is designed for service or scope unit. If that option is specified then given string is parsed again by bus_append_unit_property_assignment(). We can AccuracySec=/WakeSystem= option to there. But we have to split given properties(by --property option) according to which unit can have that properties. Hmm, the implied rule here is that we do not intrdouce properties with the same name on different unit types that do not shrae the same signature. That way it really doesn't matter to specify which properties can be parsed for a specific unit type on the client side, since the server side will already know. Or in other words: go ahead, add this to bus_append_unit_property_assignment(), and the server side will deny what it doesn't like. Hope that makes sense, 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] [PATCH v5] udev hwdb: Support shipping pre-compiled database in system images
On Tue, 28.10.14 09:53, Martin Pitt (martin.p...@ubuntu.com) wrote:
Hello Lennart,
Lennart Poettering [2014-10-27 16:09 +0100]:
+static const char hwdb_bin_paths[] =
+/etc/udev/hwdb.bin\0
+UDEVLIBEXECDIR /hwdb.bin\0;
+
+
+static int open_hwdb_bin(const char **path, FILE** f) {
+const char* p;
+
+NULSTR_FOREACH(p, hwdb_bin_paths) {
+*path = p;
Please do not write functions that clobber passed-in arguments on
failure. Please store any result in a temporary variable first, and
clobber the passed-in variables only on success.
+*f = fopen(p, re);
same here.
Done for the FILE*, but I kept the behaviour for the path as the
caller uses the path in the error message on failure. I added a
comment to clarify this.
I'd prefer if you'd move the log message for the error into
open_hwdb_bin() then, so that it is not the caller, but the callee
which prints the error message in this case.
Otherwise looks good.
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 presentation slides?
Hi Mihamina, On Tue, Oct 28, 2014 at 11:06 AM, Mihamina Rakotomandimby mihamina.rakotomandi...@rktmb.org wrote: Would you have some bookmarks of some slide presenting systemd? We try to gather all such resources here: http://www.freedesktop.org/wiki/Software/systemd/. HTH, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v6] udev hwdb: Support shipping pre-compiled database in system images
Hello Lennart,
Lennart Poettering [2014-10-28 11:31 +0100]:
I'd prefer if you'd move the log message for the error into
open_hwdb_bin() then, so that it is not the caller, but the callee
which prints the error message in this case.
That would then mean to move most of udev_hwdb_new() into
open_hwdb_bin(). As the latter is only used once, I instead moved that
logic into udev_hwdb_new(), which also simplifies it somewhat. I also
added a new and clearer error message if hwdb.bin doesn't exist
anywhere.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From cec6833eb90b6211134ab151b00700f8032914d0 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Fri, 17 Oct 2014 15:01:01 +0200
Subject: [PATCH] udev hwdb: Support shipping pre-compiled database in system
images
In some cases it is preferable to ship system images with a pre-generated
binary hwdb database, to avoid having to build it at runtime, avoid shipping
the source hwdb files, or avoid storing large binary files in /etc.
So if hwdb.bin does not exist in /etc/udev/, fall back to looking for it in
UDEVLIBEXECDIR. This keeps the possibility to add files to /etc/udev/hwdb.d/
and re-generating the database which trumps the one in /usr/lib.
Add a new --usr flag to udevadm hwdb --update which puts the database
into UDEVLIBEXECDIR.
Adjust systemd-udev-hwdb-update.service to not generate the file in /etc if we
already have it in /usr.
---
man/udev.xml | 4 ++-
man/udevadm.xml | 9 +++
src/libudev/libudev-hwdb.c| 42 ++-
src/udev/udevadm-hwdb.c | 13 +-
units/systemd-udev-hwdb-update.service.in | 3 +++
5 files changed, 63 insertions(+), 8 deletions(-)
diff --git a/man/udev.xml b/man/udev.xml
index d77cbb0..87c16c7 100644
--- a/man/udev.xml
+++ b/man/udev.xml
@@ -766,7 +766,9 @@
paraThe content of all hwdb files is read by
citerefentryrefentrytitleudevadm/refentrytitlemanvolnum8/manvolnum/citerefentry
- and compiled to a binary database located at filename/etc/udev/hwdb.bin/filename.
+ and compiled to a binary database located at filename/etc/udev/hwdb.bin/filename,
+ or alternatively filename/usr/lib/udev/hwdb.bin/filename if you want ship the compiled
+ database in an immutable image.
During runtime only the binary database is used./para
/refsect1
diff --git a/man/udevadm.xml b/man/udevadm.xml
index 749144d..b85d9a9 100644
--- a/man/udevadm.xml
+++ b/man/udevadm.xml
@@ -494,6 +494,15 @@
/listitem
/varlistentry
varlistentry
+ termoption--usr/option/term
+ listitem
+paraPut the compiled database into filename/usr/lib/udev/hwdb.bin/filename instead.
+Use this if you want to ship a pre-compiled database in immutable system images, or
+don't use filename/etc/udev/hwdb.d/filename and want to avoid large binary files in
+filename/etc/filename./para
+ /listitem
+/varlistentry
+varlistentry
termoption-t/option/term
termoption--test=replaceablestring/replaceable/option/term
listitem
diff --git a/src/libudev/libudev-hwdb.c b/src/libudev/libudev-hwdb.c
index 8fb7240..a1cfc0b 100644
--- a/src/libudev/libudev-hwdb.c
+++ b/src/libudev/libudev-hwdb.c
@@ -256,6 +256,11 @@ static int trie_search_f(struct udev_hwdb *hwdb, const char *search) {
return 0;
}
+static const char hwdb_bin_paths[] =
+/etc/udev/hwdb.bin\0
+UDEVLIBEXECDIR /hwdb.bin\0;
+
+
/**
* udev_hwdb_new:
* @udev: udev library context
@@ -266,6 +271,7 @@ static int trie_search_f(struct udev_hwdb *hwdb, const char *search) {
**/
_public_ struct udev_hwdb *udev_hwdb_new(struct udev *udev) {
struct udev_hwdb *hwdb;
+const char *hwdb_bin_path;
const char sig[] = HWDB_SIG;
hwdb = new0(struct udev_hwdb, 1);
@@ -275,30 +281,43 @@ _public_ struct udev_hwdb *udev_hwdb_new(struct udev *udev) {
hwdb-refcount = 1;
udev_list_init(udev, hwdb-properties_list, true);
-hwdb-f = fopen(/etc/udev/hwdb.bin, re);
+/* find hwdb.bin in hwdb_bin_paths */
+NULSTR_FOREACH(hwdb_bin_path, hwdb_bin_paths) {
+hwdb-f = fopen(hwdb_bin_path, re);
+if (hwdb-f)
+break;
+else if (errno == ENOENT)
+continue;
+else {
+udev_dbg(udev, error reading %s: %m, hwdb_bin_path);
+udev_hwdb_unref(hwdb);
+return NULL;
+}
+}
+
if (!hwdb-f) {
-udev_dbg(udev, error reading /etc/udev/hwdb.bin: %m);
+udev_err(udev, hwdb.bin does not exist, please run udevadm hwdb
Re: [systemd-devel] [PATCH] swap: rework discard
On Thu, 23.10.14 16:39, Lennart Poettering (lenn...@poettering.net) wrote: Heya, Hmm, I think the generator should already treat the option fields the same way as I want it to work in the long run, i.e. just read it from fstab and write it 1:1 into the unit's Options= string. I am hacking up a patch for this now, since I really want to get the new release out of the door soon. 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] [PATCH 3/3] run: introduce timer support option
On 10/28/2014 07:22 PM, Lennart Poettering wrote: On Tue, 28.10.14 12:09, WaLyong Cho (walyong@samsung.com) wrote: The AccuracySec= and WakeSystem= stuff I think we don't need to cover with a command line argument of its own, we can cover that with --property=. Rework is almost done. Now I'm testing. But the AccuracySec= and WakeSystem= options are hard to deal with --property= option. Currently the --property= option of systemd-run is designed for service or scope unit. If that option is specified then given string is parsed again by bus_append_unit_property_assignment(). We can AccuracySec=/WakeSystem= option to there. But we have to split given properties(by --property option) according to which unit can have that properties. Hmm, the implied rule here is that we do not intrdouce properties with the same name on different unit types that do not shrae the same signature. That way it really doesn't matter to specify which properties can be parsed for a specific unit type on the client side, since the server side will already know. Or in other words: go ahead, add this to bus_append_unit_property_assignment(), and the server side will deny what it doesn't like. Honestly, I'd tried. But that was denied by server side. The properties of received transient unit are set by bus_unit_set_properties. Currently, bus_unit_set_properties return fail for unknown property. See this example, systemd-run --on-unit-active=30 --property=AccuracySec=100ms touch /tmp/hello On the client side, systemd-run ship the AccuracySec=100ms option to both timer and service(aux unit) property. Because bus_append_unit_property_assignment don't know that is working on which kind of unit. Anyway the message is successfully made and sent to systemd(server side). There is no problem on parse timer unit properties. But when parse aux unit(maybe run-xxx.service), bus_unit_set_properties try to parse AccuracySec= but it can not. And return fail with Cannot set property AccuracySec, or unknown property. I think we have to pass unit type to bus_append_unit_property_assignment and only be assigned what be supported by its unit type. Hope that makes sense, Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Need suggsetion on weird characters on RHEL7 !
Hello, I need suggestion on a case 01270671, where customer is getting weird characters as below : Can some one suggest what is wrong? Weird characters when displaying man pages on RHEL 7.0 e.g. man firewall-cmd ample 2 Enable port 443/tcp immediately and permanently in default zone. To make the change effective immediately and also after restart we need two commands. The first command makes the change in runtime configuration, i.e. makes it effective immediately, until restart. The second command makes the change in permanent configuration, i.e. makes it effective after restart. firewall-cmd --add-port=443/tcp firewall-cmd --permanent --add-port=443/tcp EXIT CODES On success 0 is returned. On failure the output is red colored and exit code is either 2 in case of wrong command-line option usage or one of the following error codes in other cases: ┌────────────────────┬──────┠│String │ Code │ ├────────────────────┼──────┤ │ALREADY_ENABLED │ 11 │ ├────────────────────┼──────┤ │NOT_ENABLED │ 12 │ ├────────────────────┼──────┤ │COMMAND_FAILED │ 13 │ ├────────────────────┼──────┤ │NO_IPV6_NAT │ 14 │ ├────────────────────┼──────┤ │PANIC_MODE │ 15 │ --- Also customer can see these characters in other commands too e.g. systemctl [root@eadmzu084p ~]# systemctl list-dependencies rpcbind.service rpcbind.service ├─rpcbind.socket ├─system.slice └─basic.target ├─firewalld.service ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target │ ├─-.slice │ └─system.slice ├─sockets.target │ ├─dbus.socket │ ├─dm-event.socket │ ├─iscsid.socket │ ├─iscsiuio.socket │ ├─lvm2-lvmetad.socket │ ├─systemd-initctl.socket │ ├─systemd-journald.socket │ ├─systemd-shutdownd.socket │ ├─systemd-udevd-control.socket │ └─systemd-udevd-kernel.socket ├─sysinit.target │ ├─dev-hugepages.mount │ ├─dev-mqueue.mount │ ├─dmraid-activation.service │ ├─iscsi.service │ ├─kmod-static-nodes.service │ ├─lvm2-monitor.service -- Here is the output of env and os-release from customer end : [root@~]# env XDG_SESSION_ID=877 HOSTNAME=eadmzu084p.ea.toyota-fs.com SHELL=/bin/bash TERM=vt100 HISTSIZE=1000 USER=root LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36: MAIL=/var/spool/mail/root PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin PWD=/root LANG=en_GB.UTF-8 HISTCONTROL=ignoredups SHLVL=1 HOME=/root LOGNAME=root LESSOPEN=||/usr/bin/lesspipe.sh %s _=/bin/env --- [root@eadmzu084p ~]# cat /etc/os-release NAME=Red Hat Enterprise Linux Server VERSION=7.0 (Maipo) ID=rhel ID_LIKE=fedora VERSION_ID=7.0 PRETTY_NAME=Red Hat Enterprise Linux ANSI_COLOR=0;31
Re: [systemd-devel] [PATCH v2] Bootchart: allow parse LABEL, UUID, PARTUUID for svg info
On Tue, Oct 28, 2014 at 07:56:32AM +0300, Timofey Titovets wrote:
Good time of day, list.
I try to fix Fixme in svg.c:
/* FIXME: this works only in the simple case */
By default function try to get only root=/dev/*
I also attach patch. Thanks.
v2:
Rewrited with use fstab_node_to_udev_node() and
canonicalize_file_name() functions.
There's infrastracture to do this properly: see
parse_proc_cmdline_item, e.g. in cryptsetup-generator.c.
Nevertheless, I'm wondering if this couldn't be done better by checking
what is mounted on /. Seems that it would work in more cases.
Zbyszek
From 4d14e78977df92e010ea488f97acd6a5e8e30e97 Mon Sep 17 00:00:00 2001
From: Timofey Titovets nefelim...@gmail.com
Date: Tue, 28 Oct 2014 07:42:26 +0300
Subject: [PATCH] Bootchart: allow parse LABEL, UUID, PARTUUID for svg info
---
src/bootchart/svg.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index faf377e..81d3da9 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -151,6 +151,24 @@ static void svg_header(void) {
svg(]]\n /style\n/defs\n\n);
}
+static void get_root_disk(const char *cmdline, char *rootbdev) {
+char *ptr = strstr(cmdline, root=);
+
+if (!ptr)
+return;
+
+ptr = ptr[5];
+ptr = strtok(ptr, );
+
+if (ptr[0] != '/') {
+ptr = fstab_node_to_udev_node(ptr);
+ptr = canonicalize_file_name(ptr);
+}
+
+strncpy(rootbdev, ptr[5], 3);
+rootbdev[3] = '\0';
+}
+
static void svg_title(const char *build) {
char cmdline[256] = ;
char filename[PATH_MAX];
@@ -175,11 +193,9 @@ static void svg_title(const char *build) {
}
/* extract root fs so we can find disk model name in sysfs */
-/* FIXME: this works only in the simple case */
-c = strstr(cmdline, root=/dev/);
+c = strstr(cmdline, root=);
if (c) {
-strncpy(rootbdev, c[10], 3);
-rootbdev[3] = '\0';
+get_root_disk(cmdline, rootbdev);
sprintf(filename, block/%s/device/model, rootbdev);
fd = openat(sysfd, filename, O_RDONLY);
f = fdopen(fd, r);
--
2.1.2
From 4d14e78977df92e010ea488f97acd6a5e8e30e97 Mon Sep 17 00:00:00 2001
From: Timofey Titovets nefelim...@gmail.com
Date: Tue, 28 Oct 2014 07:42:26 +0300
Subject: [PATCH] Bootchart: allow parse LABEL, UUID, PARTUUID for svg info
---
src/bootchart/svg.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index faf377e..81d3da9 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -151,6 +151,24 @@ static void svg_header(void) {
svg(]]\n /style\n/defs\n\n);
}
+static void get_root_disk(const char *cmdline, char *rootbdev) {
+char *ptr = strstr(cmdline, root=);
+
+if (!ptr)
+return;
+
+ptr = ptr[5];
+ptr = strtok(ptr, );
+
+if (ptr[0] != '/') {
+ptr = fstab_node_to_udev_node(ptr);
+ptr = canonicalize_file_name(ptr);
+}
+
+strncpy(rootbdev, ptr[5], 3);
+rootbdev[3] = '\0';
+}
+
static void svg_title(const char *build) {
char cmdline[256] = ;
char filename[PATH_MAX];
@@ -175,11 +193,9 @@ static void svg_title(const char *build) {
}
/* extract root fs so we can find disk model name in sysfs */
-/* FIXME: this works only in the simple case */
-c = strstr(cmdline, root=/dev/);
+c = strstr(cmdline, root=);
if (c) {
-strncpy(rootbdev, c[10], 3);
-rootbdev[3] = '\0';
+get_root_disk(cmdline, rootbdev);
sprintf(filename, block/%s/device/model, rootbdev);
fd = openat(sysfd, filename, O_RDONLY);
f = fdopen(fd, r);
--
2.1.2
___
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] Need suggsetion on weird characters on RHEL7 !
From memory that's pretty standard with vt100 emulation, I always noticed it in man pages .. have they tried setting TERM to xterm? - Original Message - From: Manish Saxena msax...@redhat.com To: systemd-devel@lists.freedesktop.org, Red Hat Technical Discussion List tech-l...@redhat.com Sent: Tuesday, 28 October, 2014 11:28:54 PM Subject: Need suggsetion on weird characters on RHEL7 ! Hello, I need suggestion on a case 01270671, where customer is getting weird characters as below : Can some one suggest what is wrong? Weird characters when displaying man pages on RHEL 7.0 e.g. man firewall-cmd ample 2 Enable port 443/tcp immediately and permanently in default zone. To make the change effective immediately and also after restart we need two commands. The first command makes the change in runtime configuration, i.e. makes it effective immediately, until restart. The second command makes the change in permanent configuration, i.e. makes it effective after restart. firewall-cmd --add-port=443/tcp firewall-cmd --permanent --add-port=443/tcp EXIT CODES On success 0 is returned. On failure the output is red colored and exit code is either 2 in case of wrong command-line option usage or one of the following error codes in other cases: ┌────────────────────┬──────┠│String │ Code │ ├────────────────────┼──────┤ │ALREADY_ENABLED │ 11 │ ├────────────────────┼──────┤ │NOT_ENABLED │ 12 │ ├────────────────────┼──────┤ │COMMAND_FAILED │ 13 │ ├────────────────────┼──────┤ │NO_IPV6_NAT │ 14 │ ├────────────────────┼──────┤ │PANIC_MODE │ 15 │ --- Also customer can see these characters in other commands too e.g. systemctl [root@eadmzu084p ~]# systemctl list-dependencies rpcbind.service rpcbind.service ├─rpcbind.socket ├─system.slice └─basic.target ├─firewalld.service ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target │ ├─-.slice │ └─system.slice ├─sockets.target │ ├─dbus.socket │ ├─dm-event.socket │ ├─iscsid.socket │ ├─iscsiuio.socket │ ├─lvm2-lvmetad.socket │ ├─systemd-initctl.socket │ ├─systemd-journald.socket │ ├─systemd-shutdownd.socket │ ├─systemd-udevd-control.socket │ └─systemd-udevd-kernel.socket ├─sysinit.target │ ├─dev-hugepages.mount │ ├─dev-mqueue.mount │ ├─dmraid-activation.service │ ├─iscsi.service │ ├─kmod-static-nodes.service │ ├─lvm2-monitor.service -- Here is the output of env and os-release from customer end : [root@~]# env XDG_SESSION_ID=877 HOSTNAME=eadmzu084p.ea.toyota-fs.com SHELL=/bin/bash TERM=vt100 HISTSIZE=1000 USER=root LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01!
Re: [systemd-devel] systemd presentation slides?
On 28/10/14 10:06, Mihamina Rakotomandimby wrote: what to do if there is the need to package a daemon and there is only a SysV init script available LSB init scripts should continue to work fine. Make sure they have LSB pseudo-headers (Required-Start etc.) for their dependencies. if running Debian what about update-rc.d and invoke-rc.d? The versions of those scripts in Debian testing (which will become Debian 8) have specific support for systemd, and so does service(8), so they should continue to work like they would for sysvinit. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need suggsetion on weird characters on RHEL7 !
On Tue, Oct 28, 2014 at 2:28 PM, Manish Saxena msax...@redhat.com wrote: Hello, I need suggestion on a case 01270671, where customer is getting weird characters as below : Can some one suggest what is wrong? Weird characters when displaying man pages on RHEL 7.0 e.g. man firewall-cmd ample 2 Enable port 443/tcp immediately and permanently in default zone. To make the change effective immediately and also after restart we need two commands. The first command makes the change in runtime configuration, i.e. makes it effective immediately, until restart. The second command makes the change in permanent configuration, i.e. makes it effective after restart. firewall-cmd --add-port=443/tcp firewall-cmd --permanent --add-port=443/tcp EXIT CODES On success 0 is returned. On failure the output is red colored and exit code is either 2 in case of wrong command-line option usage or one of the following error codes in other cases: ┌────────────────────┬──────┠│String │ Code │ ├────────────────────┼──────┤ │ALREADY_ENABLED │ 11 │ ├────────────────────┼──────┤ │NOT_ENABLED │ 12 │ ├────────────────────┼──────┤ │COMMAND_FAILED │ 13 │ ├────────────────────┼──────┤ │NO_IPV6_NAT │ 14 │ ├────────────────────┼──────┤ │PANIC_MODE │ 15 │ What you're seeing here is a table or a tree drawn using the Unicode line-drawing characters, which `man` outputs encoded as UTF-8 (due to the correct $LANG), but your terminal emulator is trying to decode each byte as ISO-8859-1 instead (usually due to wrong, or lack of, $LANG in its own environment). You didn't mention /which/ terminal emulator is used: * For the Linux console, UTF-8 mode is enabled by systemd-vconsole-setup.service, but only when the system locale is a UTF-8 one (that is, when /etc/locale.conf has LANG=en_GB.UTF-8 or something such). [Note that some things might accidentally turn off the UTF-8 mode or prevent it from being enabled; there was another thread just last week about such problems.] Check src/vconsole-setup/vconsole-setup.c:enable_utf8 to see how it's done. * For X11 terminal emulators, having $LANG in environment should be enough. This problem usually occurs when $LANG is being set in the wrong place (e.g. ~/.bashrc), so the shell has it but the terminal emulator doesn't. You can verify this by checking /proc/pid/environ. * Various layers like tmux or screen can also have the same problem as X11 terminals above ($LANG correct inside but wrong outside). * Older versions of screen can't read locale settings and need UTF-8 mode enabled explicitly using `screen -U`. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need suggsetion on weird characters on RHEL7 !
Thanks everyone, actually customer was using some third party software to access the terminal which they confirmed now. and they are not facing any issue while using console or ssh. Thanks for help and sorry for noise. Regards, Manish - Original Message - From: Morgan Weetman mweet...@redhat.com To: Red Hat Technical Discussion List tech-l...@redhat.com Cc: systemd-devel@lists.freedesktop.org Sent: Tuesday, October 28, 2014 6:09:26 PM Subject: Re: Need suggsetion on weird characters on RHEL7 ! From memory that's pretty standard with vt100 emulation, I always noticed it in man pages .. have they tried setting TERM to xterm? - Original Message - From: Manish Saxena msax...@redhat.com To: systemd-devel@lists.freedesktop.org, Red Hat Technical Discussion List tech-l...@redhat.com Sent: Tuesday, 28 October, 2014 11:28:54 PM Subject: Need suggsetion on weird characters on RHEL7 ! Hello, I need suggestion on a case 01270671, where customer is getting weird characters as below : Can some one suggest what is wrong? Weird characters when displaying man pages on RHEL 7.0 e.g. man firewall-cmd ample 2 Enable port 443/tcp immediately and permanently in default zone. To make the change effective immediately and also after restart we need two commands. The first command makes the change in runtime configuration, i.e. makes it effective immediately, until restart. The second command makes the change in permanent configuration, i.e. makes it effective after restart. firewall-cmd --add-port=443/tcp firewall-cmd --permanent --add-port=443/tcp EXIT CODES On success 0 is returned. On failure the output is red colored and exit code is either 2 in case of wrong command-line option usage or one of the following error codes in other cases: ┌────────────────────┬──────┠│String │ Code │ ├────────────────────┼──────┤ │ALREADY_ENABLED │ 11 │ ├────────────────────┼──────┤ │NOT_ENABLED │ 12 │ ├────────────────────┼──────┤ │COMMAND_FAILED │ 13 │ ├────────────────────┼──────┤ │NO_IPV6_NAT │ 14 │ ├────────────────────┼──────┤ │PANIC_MODE │ 15 │ --- Also customer can see these characters in other commands too e.g. systemctl [root@eadmzu084p ~]# systemctl list-dependencies rpcbind.service rpcbind.service ├─rpcbind.socket ├─system.slice └─basic.target ├─firewalld.service ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target │ ├─-.slice │ └─system.slice ├─sockets.target │ ├─dbus.socket │ ├─dm-event.socket │ ├─iscsid.socket │ ├─iscsiuio.socket │ ├─lvm2-lvmetad.socket │ ├─systemd-initctl.socket │ ├─systemd-journald.socket │ ├─systemd-shutdownd.socket │ ├─systemd-udevd-control.socket │ └─systemd-udevd-kernel.socket ├─sysinit.target │ ├─dev-hugepages.mount │ ├─dev-mqueue.mount │ ├─dmraid-activation.service │ ├─iscsi.service │ ├─kmod-static-nodes.service │ ├─lvm2-monitor.service -- Here is the output of env and os-release from customer end : [root@~]# env XDG_SESSION_ID=877 HOSTNAME=eadmzu084p.ea.toyota-fs.com SHELL=/bin/bash TERM=vt100 HISTSIZE=1000 USER=root
Re: [systemd-devel] [PATCH 3/3] run: introduce timer support option
On Tue, 28.10.14 21:17, WaLyong Cho (walyong@samsung.com) wrote: On 10/28/2014 07:22 PM, Lennart Poettering wrote: On Tue, 28.10.14 12:09, WaLyong Cho (walyong@samsung.com) wrote: The AccuracySec= and WakeSystem= stuff I think we don't need to cover with a command line argument of its own, we can cover that with --property=. Rework is almost done. Now I'm testing. But the AccuracySec= and WakeSystem= options are hard to deal with --property= option. Currently the --property= option of systemd-run is designed for service or scope unit. If that option is specified then given string is parsed again by bus_append_unit_property_assignment(). We can AccuracySec=/WakeSystem= option to there. But we have to split given properties(by --property option) according to which unit can have that properties. Hmm, the implied rule here is that we do not intrdouce properties with the same name on different unit types that do not shrae the same signature. That way it really doesn't matter to specify which properties can be parsed for a specific unit type on the client side, since the server side will already know. Or in other words: go ahead, add this to bus_append_unit_property_assignment(), and the server side will deny what it doesn't like. Honestly, I'd tried. But that was denied by server side. The properties of received transient unit are set by bus_unit_set_properties. Currently, bus_unit_set_properties return fail for unknown property. See this example, You need to register a callback that parses the timer unit properties in the timer unit vtable, as field .bus_set_property. See how .service and .scope units do this. systemd-run --on-unit-active=30 --property=AccuracySec=100ms touch /tmp/hello On the client side, systemd-run ship the AccuracySec=100ms option to both timer and service(aux unit) property. Because bus_append_unit_property_assignment don't know that is working on which kind of unit. Anyway the message is successfully made and sent to systemd(server side). There is no problem on parse timer unit properties. But when parse aux unit(maybe run-xxx.service), bus_unit_set_properties try to parse AccuracySec= but it can not. And return fail with Cannot set property AccuracySec, or unknown property. I think we have to pass unit type to bus_append_unit_property_assignment and only be assigned what be supported by its unit type. Sure, but that's already in place via the vtable indirection. 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] [PATCH v6] udev hwdb: Support shipping pre-compiled database in system images
On Tue, 28.10.14 12:18, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello Lennart, Checked with Kay, he's fine with this. Please commit! Thanks, 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] [PATCH] mac: add mac_ prefix to distinguish origin security apis
On Fri, 24.10.14 21:15, WaLyong Cho (walyong@samsung.com) wrote: Thanks! Applied! --- src/core/dbus-job.c | 2 +- src/core/dbus-manager.c | 68 +++ src/core/dbus-snapshot.c | 2 +- src/core/dbus-unit.c | 8 +++--- src/core/dbus.c | 8 +++--- src/core/main.c | 4 +-- src/core/selinux-access.c | 46 +++- src/core/selinux-access.h | 18 ++--- src/core/selinux-setup.c | 2 +- src/core/selinux-setup.h | 2 +- src/core/smack-setup.c| 2 +- src/core/smack-setup.h| 2 +- 12 files changed, 74 insertions(+), 90 deletions(-) diff --git a/src/core/dbus-job.c b/src/core/dbus-job.c index 3f7a28a..09f5739 100644 --- a/src/core/dbus-job.c +++ b/src/core/dbus-job.c @@ -80,7 +80,7 @@ int bus_job_method_cancel(sd_bus *bus, sd_bus_message *message, void *userdata, if (r 0) return r; -r = selinux_unit_access_check(j-unit, message, stop, error); +r = mac_selinux_unit_access_check(j-unit, message, stop, error); if (r 0) return r; diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c index 57db1c9..c54abd3 100644 --- a/src/core/dbus-manager.c +++ b/src/core/dbus-manager.c @@ -363,7 +363,7 @@ static int method_get_unit(sd_bus *bus, sd_bus_message *message, void *userdata, if (!u) return sd_bus_error_setf(error, BUS_ERROR_NO_SUCH_UNIT, Unit %s not loaded., name); -r = selinux_unit_access_check(u, message, status, error); +r = mac_selinux_unit_access_check(u, message, status, error); if (r 0) return r; @@ -409,7 +409,7 @@ static int method_get_unit_by_pid(sd_bus *bus, sd_bus_message *message, void *us if (!u) return sd_bus_error_setf(error, BUS_ERROR_NO_UNIT_FOR_PID, PID %u does not belong to any loaded unit., pid); -r = selinux_unit_access_check(u, message, status, error); +r = mac_selinux_unit_access_check(u, message, status, error); if (r 0) return r; @@ -441,7 +441,7 @@ static int method_load_unit(sd_bus *bus, sd_bus_message *message, void *userdata if (r 0) return r; -r = selinux_unit_access_check(u, message, status, error); +r = mac_selinux_unit_access_check(u, message, status, error); if (r 0) return r; @@ -648,7 +648,7 @@ static int method_start_transient_unit(sd_bus *bus, sd_bus_message *message, voi if (mode 0) return sd_bus_error_setf(error, SD_BUS_ERROR_INVALID_ARGS, Job mode %s is invalid., smode); -r = selinux_access_check(message, start, error); +r = mac_selinux_access_check(message, start, error); if (r 0) return r; @@ -702,7 +702,7 @@ static int method_get_job(sd_bus *bus, sd_bus_message *message, void *userdata, if (!j) return sd_bus_error_setf(error, BUS_ERROR_NO_SUCH_JOB, Job %u does not exist., (unsigned) id); -r = selinux_unit_access_check(j-unit, message, status, error); +r = mac_selinux_unit_access_check(j-unit, message, status, error); if (r 0) return r; @@ -742,7 +742,7 @@ static int method_clear_jobs(sd_bus *bus, sd_bus_message *message, void *userdat assert(message); assert(m); -r = selinux_access_check(message, reboot, error); +r = mac_selinux_access_check(message, reboot, error); if (r 0) return r; @@ -759,7 +759,7 @@ static int method_reset_failed(sd_bus *bus, sd_bus_message *message, void *userd assert(message); assert(m); -r = selinux_access_check(message, reload, error); +r = mac_selinux_access_check(message, reload, error); if (r 0) return r; @@ -782,7 +782,7 @@ static int list_units_filtered(sd_bus *bus, sd_bus_message *message, void *userd /* Anyone can call this method */ -r = selinux_access_check(message, status, error); +r = mac_selinux_access_check(message, status, error); if (r 0) return r; @@ -870,7 +870,7 @@ static int method_list_jobs(sd_bus *bus, sd_bus_message *message, void *userdata /* Anyone can call this method */ -r = selinux_access_check(message, status, error); +r = mac_selinux_access_check(message, status, error); if (r 0) return r; @@ -922,7 +922,7 @@ static int method_subscribe(sd_bus *bus, sd_bus_message *message, void *userdata /* Anyone can call this method */ -r = selinux_access_check(message, status, error); +r = mac_selinux_access_check(message, status, error);
Re: [systemd-devel] [PATCH 3/4] manager: stop start timeout when sysinit.target is reached
On Tue, Oct 28, 2014 at 10:50:05AM +0100, Lennart Poettering wrote: On Tue, 28.10.14 03:52, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Oct 28, 2014 at 02:32:37AM +0100, Lennart Poettering wrote: On Mon, 27.10.14 23:07, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 27.10.14 20:03, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Oct 27, 2014 at 06:51:08PM +0100, Lennart Poettering wrote: On Sat, 25.10.14 21:43, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: +if (result == JOB_DONE unit_has_name(u, SPECIAL_SYSINIT_TARGET)) +manager_cancel_start_timeout(u-manager); + I'd really prefer to hook this up with manager_state(), so that we don't have to hardcode the target name more than once, and so that we know that the rescue/emergency mode is properly handled... Yeah, I thought about that too, but only after I sent the patch. I'l look into hacking this up now, I really want to get the release out of the door now. I hacked this up now. Though after thinking forth and back quite differently than what we had before. I now removed the system-wide timeout, in favour of beefing up the existing JobTimeoutSec= stuff we have in units, so that we can set per-unit timeouts that trigger failure actions. With this in place I have now set default timeouts of 15min on basic.target and 30min on poweroff.target+reboot.target. Good, that sounds more flexible (and simpler). I'll push the change to avoid clobbering of password prompts. Hmm, did you see my comments about using BSD file locks for locking access to /dev/console, instead of explict checks for the ask-passwor stuff? http://lists.freedesktop.org/archives/systemd-devel/2014-October/024582.html Oops, I see it now. It does seem to be a better solution. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] manager: do not print anything while passwords are being queried
On Mon, Oct 27, 2014 at 06:37:21PM +0100, Lennart Poettering wrote: On Sun, 26.10.14 05:37, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: https://bugs.freedesktop.org/show_bug.cgi?id=73942 So in really old systemd versions I had a concept in place of never printing to the console if there was a controlling process on it. The kernel's concept of a controlling process we used as a somewhat natural synchronization on the tty. However, this functionality has pretty much been lost. I am not entirely sure what happened between all the reworks there, but maybe we should just resurrect that scheme? Suppressing output on the console if there's a controlling process would not just automatically avoid mixing password queries with getty login prompts, but also all other cases where some process wants exclusive ownership of the tty. Using the controlling tty for this would be somewhat nice, as all users of the tty would just work with it. Another idea could be to use BSD locks on the /dev/console device node. Everybody with access on the tty could take one of the logs. We would even have R/W locks then, where the status output would just take a read lock, while things like gettys and the password stuff would take a full write lock. I don't get this r/w distinction. In either case access has to be exclusive. Either solution appears nicer to me then explicitly hooking up PID 1 with the ask-password stuff, in particularly, because we really should look into moving hte ask-password onto kdbus and the kernel keyring, and we hence shouldn't add cross-links to it now, where we already know it should probably go away the way it currently is. The BSD lock scheme would be pretty much race-free afaics. The controlling process stuff otoh would be race-ful, probably to the same level as watching the ask-password stuff. Anyway, opinions on this? Like it. I am slightly leaning towards the BSD lock solution I must say. In particular as it is compatible with the story we kinda want to push people using /dev/ttyS* towards, who really should use BSD locks too, instead of the awful LCK.. files... Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] manager: do not print anything while passwords are being queried
On Tue, 28.10.14 15:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Oct 27, 2014 at 06:37:21PM +0100, Lennart Poettering wrote: On Sun, 26.10.14 05:37, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: https://bugs.freedesktop.org/show_bug.cgi?id=73942 So in really old systemd versions I had a concept in place of never printing to the console if there was a controlling process on it. The kernel's concept of a controlling process we used as a somewhat natural synchronization on the tty. However, this functionality has pretty much been lost. I am not entirely sure what happened between all the reworks there, but maybe we should just resurrect that scheme? Suppressing output on the console if there's a controlling process would not just automatically avoid mixing password queries with getty login prompts, but also all other cases where some process wants exclusive ownership of the tty. Using the controlling tty for this would be somewhat nice, as all users of the tty would just work with it. Another idea could be to use BSD locks on the /dev/console device node. Everybody with access on the tty could take one of the logs. We would even have R/W locks then, where the status output would just take a read lock, while things like gettys and the password stuff would take a full write lock. I don't get this r/w distinction. In either case access has to be exclusive. Well, so, on the console it is fine if five clients write messages at the same time (as long as they print full lines at a time). However, only one client should read fro it at the same time, as otherwise it's pretty much random which component will actually get the input. We can use the BSD LOCK_SH vs. LOCK_EX bits for this. LOCK_SH is for everything which wants to just print a status message, LOCK_EX is for everything which wants to also read input. The weird bit of course is that in this case the writers take shared locks and the readers exclusive locks, even though classic R/W locks are of course the other way round... I am slightly leaning towards the BSD lock solution I must say. In particular as it is compatible with the story we kinda want to push people using /dev/ttyS* towards, who really should use BSD locks too, instead of the awful LCK.. files... One question remains though: which part shall take the LOCK_EX locks? I figure this should be agetty. Karel, can we convince you to take a LOCK_EX BSD file lock on the tty devices agetty opens? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2] core: send sigabrt on watchdog timeout to get the stacktrace
if sigabrt doesn't do the job, follow regular shutdown
routine, sigterm sigkill.
Umut:
- I have done basic testing with suppressing sigabrt,
suppressing both sigabrt sigterm on client application.
- Documentation needs to be updated. I wasn't sure if we
should mention it in KillMode, KillSignal or WatchdogSec
---
TODO | 2 --
src/core/busname.c | 2 +-
src/core/mount.c | 3 ++-
src/core/scope.c | 2 +-
src/core/service.c | 37 ++---
src/core/service.h | 1 +
src/core/socket.c | 3 ++-
src/core/swap.c| 3 ++-
src/core/unit.c| 24 ++--
src/core/unit.h| 8 +++-
10 files changed, 60 insertions(+), 25 deletions(-)
diff --git a/TODO b/TODO
index acac4e3..3e85eee 100644
--- a/TODO
+++ b/TODO
@@ -54,8 +54,6 @@ Features:
* consider showing the unit names during boot up in the status output, not
just the unit descriptions
-* send SIGABRT when a service watchdog is triggered, by default, so that we
acquire a backtrace of the hang.
-
* dhcp: do we allow configuring dhcp routes on interfaces that are not the one
we got the dhcp info from?
* maybe allow timer units with an empty Units= setting, so that they
diff --git a/src/core/busname.c b/src/core/busname.c
index 22d2a6d..68cb6ca 100644
--- a/src/core/busname.c
+++ b/src/core/busname.c
@@ -446,7 +446,7 @@ static void busname_enter_signal(BusName *n, BusNameState
state, BusNameResult f
r = unit_kill_context(UNIT(n),
kill_context,
- state != BUSNAME_SIGTERM,
+ state != BUSNAME_SIGTERM ? KILL_KILL :
KILL_TERMINATE,
-1,
n-control_pid,
false);
diff --git a/src/core/mount.c b/src/core/mount.c
index e284357..01243c3 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -775,7 +775,8 @@ static void mount_enter_signal(Mount *m, MountState state,
MountResult f) {
r = unit_kill_context(
UNIT(m),
m-kill_context,
-state != MOUNT_MOUNTING_SIGTERM state !=
MOUNT_UNMOUNTING_SIGTERM state != MOUNT_REMOUNTING_SIGTERM,
+(state != MOUNT_MOUNTING_SIGTERM state !=
MOUNT_UNMOUNTING_SIGTERM state != MOUNT_REMOUNTING_SIGTERM) ?
+KILL_KILL : KILL_TERMINATE,
-1,
m-control_pid,
false);
diff --git a/src/core/scope.c b/src/core/scope.c
index e8f9e8d..0f7c1f9 100644
--- a/src/core/scope.c
+++ b/src/core/scope.c
@@ -243,7 +243,7 @@ static void scope_enter_signal(Scope *s, ScopeState state,
ScopeResult f) {
r = unit_kill_context(
UNIT(s),
s-kill_context,
-state != SCOPE_STOP_SIGTERM,
+state != SCOPE_STOP_SIGTERM ? KILL_KILL :
KILL_TERMINATE,
-1, -1, false);
if (r 0)
goto fail;
diff --git a/src/core/service.c b/src/core/service.c
index d160c4e..2b16778 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -56,6 +56,7 @@ static const UnitActiveState
state_translation_table[_SERVICE_STATE_MAX] = {
[SERVICE_EXITED] = UNIT_ACTIVE,
[SERVICE_RELOAD] = UNIT_RELOADING,
[SERVICE_STOP] = UNIT_DEACTIVATING,
+[SERVICE_STOP_SIGABRT] = UNIT_DEACTIVATING,
[SERVICE_STOP_SIGTERM] = UNIT_DEACTIVATING,
[SERVICE_STOP_SIGKILL] = UNIT_DEACTIVATING,
[SERVICE_STOP_POST] = UNIT_DEACTIVATING,
@@ -76,6 +77,7 @@ static const UnitActiveState
state_translation_table_idle[_SERVICE_STATE_MAX] =
[SERVICE_EXITED] = UNIT_ACTIVE,
[SERVICE_RELOAD] = UNIT_RELOADING,
[SERVICE_STOP] = UNIT_DEACTIVATING,
+[SERVICE_STOP_SIGABRT] = UNIT_DEACTIVATING,
[SERVICE_STOP_SIGTERM] = UNIT_DEACTIVATING,
[SERVICE_STOP_SIGKILL] = UNIT_DEACTIVATING,
[SERVICE_STOP_POST] = UNIT_DEACTIVATING,
@@ -663,7 +665,7 @@ static void service_set_state(Service *s, ServiceState
state) {
SERVICE_START_PRE, SERVICE_START, SERVICE_START_POST,
SERVICE_RELOAD,
SERVICE_STOP, SERVICE_STOP_SIGTERM, SERVICE_STOP_SIGKILL,
-SERVICE_STOP_POST,
+SERVICE_STOP_SIGABRT, SERVICE_STOP_POST,
SERVICE_FINAL_SIGTERM, SERVICE_FINAL_SIGKILL,
SERVICE_AUTO_RESTART))
s-timer_event_source =
sd_event_source_unref(s-timer_event_source);
@@ -672,7 +674,7 @@ static void service_set_state(Service *s, ServiceState
state) {
SERVICE_START, SERVICE_START_POST,
SERVICE_RUNNING, SERVICE_RELOAD,
SERVICE_STOP,
Re: [systemd-devel] [PATCH] swap: rework discard
On Tue, 28.10.14 13:14, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 23.10.14 16:39, Lennart Poettering (lenn...@poettering.net) wrote: Heya, Hmm, I think the generator should already treat the option fields the same way as I want it to work in the long run, i.e. just read it from fstab and write it 1:1 into the unit's Options= string. I am hacking up a patch for this now, since I really want to get the new release out of the door soon. OK, landed that patch now. Didn't test it much though. Please test! 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] [PATCHv2] core: send sigabrt on watchdog timeout to get the stacktrace
On Tue, 28.10.14 15:34, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: if sigabrt doesn't do the job, follow regular shutdown routine, sigterm sigkill. Umut: - I have done basic testing with suppressing sigabrt, suppressing both sigabrt sigterm on client application. - Documentation needs to be updated. I wasn't sure if we should mention it in KillMode, KillSignal or WatchdogSec Looks great. I think documenation next to WatchdogSec= would be best! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] NEWS: fix typos
--- NEWS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index c5f0db2..f4afcf6 100644 --- a/NEWS +++ b/NEWS @@ -70,7 +70,7 @@ CHANGES WITH 217: * Udev rules can now remove tags on devices with TAG-=foobar. * systemd's readahead implementation has been removed. In many - circumstatances it didn't give expected benefits even for + circumstances it didn't give expected benefits even for rotational disk drives and was becoming less relevant in the age of SSDs. As none of the developers has been using rotating media anymore, and nobody stepped up to actively @@ -133,7 +133,7 @@ CHANGES WITH 217: rootfstype= but allow mounting a specific file system to /usr. -* The $NOTIFY_SOCKET is now also passed to control processesof +* The $NOTIFY_SOCKET is now also passed to control processes of services, not only the main process. * This version reenables support for fsck's -l switch. This -- 2.1.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] NEWS: fix typos
Applied. Thanks! Tom On Tue, Oct 28, 2014 at 4:04 PM, Ronny Chevalier chevalier.ro...@gmail.com wrote: --- NEWS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index c5f0db2..f4afcf6 100644 --- a/NEWS +++ b/NEWS @@ -70,7 +70,7 @@ CHANGES WITH 217: * Udev rules can now remove tags on devices with TAG-=foobar. * systemd's readahead implementation has been removed. In many - circumstatances it didn't give expected benefits even for + circumstances it didn't give expected benefits even for rotational disk drives and was becoming less relevant in the age of SSDs. As none of the developers has been using rotating media anymore, and nobody stepped up to actively @@ -133,7 +133,7 @@ CHANGES WITH 217: rootfstype= but allow mounting a specific file system to /usr. -* The $NOTIFY_SOCKET is now also passed to control processesof +* The $NOTIFY_SOCKET is now also passed to control processes of services, not only the main process. * This version reenables support for fsck's -l switch. This -- 2.1.2 ___ 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] I wonder… why systemd provokes this amount of polarity and resistance
From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl That mostly applies to people who actually don't use systemd and are commenting from the peanut gallery. Actual *users* when they are unhappy are unhappy about bugs. That is not entirely true. I'm a user (because systemd is in Fedora 19), and I've complained that if I mark an /etc/fstab entry as nofail, some part of systemd will wait *forever* to see if the partition becomes available, whereas the behavior that I want (which was provided in earlier Fedora releases) is that once the system gets to the point of user logins, it will give up on automatic booting (and leave it to manual control). I've not received any useful feedback on how to customize my system to behave that way, and no indication that there is any intention to add it as a feature. So it is clear that this is not a bug, as it is the behavior intended by the designers, but I'm still not happy. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 28/10/14 16:28, Dale R. Worley wrote: From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl That mostly applies to people who actually don't use systemd and are commenting from the peanut gallery. Actual *users* when they are unhappy are unhappy about bugs. That is not entirely true. I'm a user (because systemd is in Fedora 19), and I've complained that if I mark an /etc/fstab entry as nofail, some part of systemd will wait *forever* to see if the partition becomes available, whereas the behavior that I want (which was provided in earlier Fedora releases) is that once the system gets to the point of user logins, it will give up on automatic booting (and leave it to manual control). I've not received any useful feedback on how to customize my system to behave that way, and no indication that there is any intention to add it as a feature. So it is clear that this is not a bug, as it is the behavior intended by the designers, but I'm still not happy. What you write above is not entirely true either: On 22/10/14 20:55, Lennart Poettering wrote: On Fri, 12.09.14 15:25, Dale R. Worley (wor...@alum.mit.edu) wrote: From: Tobias Geerinckx-Rice tobias.geerinckx.r...@gmail.com Step back, and define exactly what it is you actually need^Wwant to do. For a certain entry in /etc/fstab (which will in practice always have the option nofail), if the device is not available until booting is over (which I'm willing to denote with a specified period of time), after that, it will not be automatically mounted if it becomes available. This is currently not available, and it sounds very special and racy to support it upstream I think. Sorry! If you want to hack something up like this, I'd recommend writing a timer unit/cronjob that creates a file $PATH after $SECONDS after boot. Then, add a drop-in file to /etc/systemd/system/$MOUNTUNIT.d/foobar.conf, and write into it: [Unit] ConditionFileExists=!/the/file/you/create That way the mount unit will always be queued, but will actually be conditionalized out $SECONDS after boot, if you follow what I mean. Hope this is helpful. Lennart Cheers, Daniele ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv3] core: send sigabrt on watchdog timeout to get the stacktrace
if sigabrt doesn't do the job, follow regular shutdown
routine, sigterm sigkill.
---
TODO| 2 --
man/systemd.service.xml | 5 +++--
src/core/busname.c | 2 +-
src/core/mount.c| 3 ++-
src/core/scope.c| 2 +-
src/core/service.c | 37 ++---
src/core/service.h | 1 +
src/core/socket.c | 3 ++-
src/core/swap.c | 3 ++-
src/core/unit.c | 24 ++--
src/core/unit.h | 8 +++-
11 files changed, 63 insertions(+), 27 deletions(-)
diff --git a/TODO b/TODO
index acac4e3..3e85eee 100644
--- a/TODO
+++ b/TODO
@@ -54,8 +54,6 @@ Features:
* consider showing the unit names during boot up in the status output, not
just the unit descriptions
-* send SIGABRT when a service watchdog is triggered, by default, so that we
acquire a backtrace of the hang.
-
* dhcp: do we allow configuring dhcp routes on interfaces that are not the one
we got the dhcp info from?
* maybe allow timer units with an empty Units= setting, so that they
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 115d169..e563b19 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -593,8 +593,9 @@
(i.e. the keep-alive ping). If the time
between two such calls is larger than
the configured time, then the service
-is placed in a failed state. By
-setting varnameRestart=/varname to
+is placed in a failed state and it will
+be terminated with varnameSIGABRT/varname.
+By setting varnameRestart=/varname to
optionon-failure/option or
optionalways/option, the service
will be automatically restarted. The
diff --git a/src/core/busname.c b/src/core/busname.c
index 22d2a6d..68cb6ca 100644
--- a/src/core/busname.c
+++ b/src/core/busname.c
@@ -446,7 +446,7 @@ static void busname_enter_signal(BusName *n, BusNameState
state, BusNameResult f
r = unit_kill_context(UNIT(n),
kill_context,
- state != BUSNAME_SIGTERM,
+ state != BUSNAME_SIGTERM ? KILL_KILL :
KILL_TERMINATE,
-1,
n-control_pid,
false);
diff --git a/src/core/mount.c b/src/core/mount.c
index e284357..01243c3 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -775,7 +775,8 @@ static void mount_enter_signal(Mount *m, MountState state,
MountResult f) {
r = unit_kill_context(
UNIT(m),
m-kill_context,
-state != MOUNT_MOUNTING_SIGTERM state !=
MOUNT_UNMOUNTING_SIGTERM state != MOUNT_REMOUNTING_SIGTERM,
+(state != MOUNT_MOUNTING_SIGTERM state !=
MOUNT_UNMOUNTING_SIGTERM state != MOUNT_REMOUNTING_SIGTERM) ?
+KILL_KILL : KILL_TERMINATE,
-1,
m-control_pid,
false);
diff --git a/src/core/scope.c b/src/core/scope.c
index e8f9e8d..0f7c1f9 100644
--- a/src/core/scope.c
+++ b/src/core/scope.c
@@ -243,7 +243,7 @@ static void scope_enter_signal(Scope *s, ScopeState state,
ScopeResult f) {
r = unit_kill_context(
UNIT(s),
s-kill_context,
-state != SCOPE_STOP_SIGTERM,
+state != SCOPE_STOP_SIGTERM ? KILL_KILL :
KILL_TERMINATE,
-1, -1, false);
if (r 0)
goto fail;
diff --git a/src/core/service.c b/src/core/service.c
index d160c4e..2b16778 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -56,6 +56,7 @@ static const UnitActiveState
state_translation_table[_SERVICE_STATE_MAX] = {
[SERVICE_EXITED] = UNIT_ACTIVE,
[SERVICE_RELOAD] = UNIT_RELOADING,
[SERVICE_STOP] = UNIT_DEACTIVATING,
+[SERVICE_STOP_SIGABRT] = UNIT_DEACTIVATING,
[SERVICE_STOP_SIGTERM] = UNIT_DEACTIVATING,
[SERVICE_STOP_SIGKILL] = UNIT_DEACTIVATING,
[SERVICE_STOP_POST] = UNIT_DEACTIVATING,
@@ -76,6 +77,7 @@ static const UnitActiveState
state_translation_table_idle[_SERVICE_STATE_MAX] =
[SERVICE_EXITED] = UNIT_ACTIVE,
[SERVICE_RELOAD] = UNIT_RELOADING,
[SERVICE_STOP] = UNIT_DEACTIVATING,
+[SERVICE_STOP_SIGABRT] = UNIT_DEACTIVATING,
[SERVICE_STOP_SIGTERM] = UNIT_DEACTIVATING,
[SERVICE_STOP_SIGKILL] = UNIT_DEACTIVATING,
[SERVICE_STOP_POST] = UNIT_DEACTIVATING,
@@ -663,7 +665,7 @@ static
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 28.10.14 11:28, Dale R. Worley (wor...@alum.mit.edu) wrote: From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl That mostly applies to people who actually don't use systemd and are commenting from the peanut gallery. Actual *users* when they are unhappy are unhappy about bugs. That is not entirely true. I'm a user (because systemd is in Fedora 19), and I've complained that if I mark an /etc/fstab entry as nofail, some part of systemd will wait *forever* to see if the partition becomes available, whereas the behavior that I want (which was provided in earlier Fedora releases) is that once the system gets to the point of user logins, it will give up on automatic booting (and leave it to manual control). I have already replied to this, and pointed out that such a scheme is inherently racy, and that this is something we will unlikely support natively in systemd. Sorry for that. And please don't make this a but it worked fine in sysvinit! thing, because it was racy there as well. I've not received any useful feedback on how to customize my system to behave that way, and no indication that there is any intention to add it as a feature. http://lists.freedesktop.org/archives/systemd-devel/2014-October/024325.html I am sorry, if this reply doesn't make you happy, but I guess we will not be able to mke everybody happy. But please be fair enough to admit that you did get a response from us, and a clear explanation that we will not support this upstream, and why we won't do so. So it is clear that this is not a bug, as it is the behavior intended by the designers, but I'm still not happy. I am sorry for 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] I wonder… why systemd provokes this amount of polarity and resistance
On Oct 28, 2014 5:05 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 28.10.14 11:28, Dale R. Worley (wor...@alum.mit.edu) wrote: That is not entirely true. I'm a user (because systemd is in Fedora 19), and I've complained that if I mark an /etc/fstab entry as nofail, some part of systemd will wait *forever* to see if the partition becomes available, whereas the behavior that I want (which was provided in earlier Fedora releases) is that once the system gets to the point of user logins, it will give up on automatic booting (and leave it to manual control). I have already replied to this, and pointed out that such a scheme is inherently racy, and that this is something we will unlikely support natively in systemd. Sorry for that. I think the actual issue here is the behavior of Type=idle, which delays the gettys for an annoying amount of time. Maybe launching the getty should shut off boot messages instead. Or maybe this should happen after a configurable IdleTimeout instead of having Type=idle always wait until end of transaction. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Lennart Poettering wrote on 27/10/14 18:11: On Thu, 23.10.14 17:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: order it after basic.target (which things are by default anyway)... My proposal now, (which is the same Damien's as I understood him): 1. pam_systemd should sync on default.target 2. by default default.target should just be an alias to basic.target. That way we have two things: a) as basic.target pulls in all sockets and busnames we know that everything that needs to be listened on is listened on by the time PAM succeeds b) if people really want they can change the default.target symlink to something else and thus add additional services into this, that may run after the sockets/busnames, but before PAM succeeds. Makes sense? Not to me. It still potentially delays user login a lot, because it conflates things which should be started by default with things which should be started before login completes. If I want to start a bunch of daemons whenever my systemd instance is running, I want to add them to default.target, that's what it is there for. I see a strong parallel with the system default.target: it specifies what should be launched on boot, but user logins are allowed much earlier. Maybe this should be made explicit and PAM should wait for a new user-login.target, which by default will simply have Wants=basic.target, but the user is free to add additional dependencies if they want to have more stuff running before they are allowed to log in. I see what you mean. But user- sounds like an unnecessary prefix, if we are already in user context, no? Maybe just login.target? Yeah this seems sensible to me. I certainly like it better than default.target It actually felt kinda weird using WantedBy=default.target seeing as this is typically a symlink under system-mode where we're much more used to using multi-user.target. Now that I've thought about it all, I'm not sure whether it is using WantedBy=default.target in user-mode that feels wrong, or NOT using WantedBy=default.target in system-mode that *should* feel wrong :p Col -- Colin Guthrie gmane(at)colin.guthr.ie 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
[systemd-devel] sysusers: Unconditional chown on /etc/{passwd, group, shadow, gshadow}? Is it sane?
Hi,
It seems we have different permissions for /etc/{g}shadow than fedora.
We don't package it as ,root,root but rather 0440,root,shadow.
We can then run some tools that need direct access as setgid rather than
full blown setuid. I'm not totally convinced of the security benefits
here (and I think actually 0440 is buggy for a setgid tool like chage -
I'd have thought it would need to be 0660 to actually change the age,
but I digress).
Is it correct that sysusers should unconditionally impose it's file
permissions? Wouldn't it be better to only do the fchmod() if the file
has been created by us and just leave it alone if not? That way, if we
do something different downstream we can just ship a tmpfiles snippet to
ensure it's owned and moded correctly as to our tastes?*
Would a patch that implemented such behaviour be welcome? Is there
anything I'd need to watch out for (thinking things like checking for
the file existing being racy or the like)?
Cheers
Col
* There could even be some magical RPM-esque hack that automatically
parses packages for files in /etc and /var and finds any that are owned
or modded differently to the overall default and automatically creates
tmpfiles snippets that are included in the rpm that would be nice.
--
Colin Guthrie
gmane(at)colin.guthr.ie
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] Writing a udev rule for U2F security tokens?
On Tue, Oct 28, 2014 at 1:40 AM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Oct 27, 2014 at 04:37:14PM -0700, Andy Lutomirski wrote:
On Mon, Oct 27, 2014 at 4:32 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Oct 27, 2014 at 04:12:30PM -0700, Andy Lutomirski wrote:
Hi-
I'd like to write a generic udev rule for U2F security tokens and to
possibly get it integrated into systemd / udev, but I'm not sure how
to write it in the first place.
U2F tokens are USB HID devices that have a usage page 0xF1D0 that
contains usage 0x01. The rule should match any hidraw device with
that property. Can this be done without a user helper? Is there an
existing helper in which it would make sense to add such a check?
Here's the draft USB forum allocation:
http://www.usb.org/developers/hidpage/HUTRR48.pdf
Here's the draft spec from the FIDO Alliance:
https://fidoalliance.org/specs/fido-u2f-HID-protocol-v1.0-rd-20141008.pdf
In practice, I expect little change between the draft and final specs,
since these devices are already for sale and Chromium supports them.
I don't understand, what would a udev rule do with these devices?
Shouldn't they be exported automatically using the hid raw interface
so that userspace can talk to them? What else needs to be done?
Wow, I clearly failed to transfer my thoughts into email...
I want to set ID_SECURITY_TOKEN=1 or, more generally, cause the
uaccess tag to be set so that users have permission to use the token.
This rule works in Fedora for the existing tokens by Yubico:
KERNEL==hidraw*, SUBSYSTEM==hidraw, ATTRS{idVendor}==1050,
ATTRS{idProduct}==0113|0114|0115|0116|0120,
ENV{ID_SECURITY_TOKEN}=1
but it won't work for other brands of U2F token.
If there's no sysfs attribute that you can read directly to determine
that it is a a U2F token, then it's not easy to write a udev rule.
You can write a simple program to read the hid pages from the hidraw
interface, and then set an environment variable from there if the FIDO
Alliance Page is present. You can use a udev rule for that, but it
will have to be an external tool.
Would a tool like that be considered appropriate to distribute with
udev? It would have somewhat unpleasant overhead for what is
currently a niche use case.
I suppose the kernel could also be modified to expose this, but doing
that cleanly will involve exposing all the usage pages in sysfs, which
is more complexity than I really want to add.
--Andy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, Oct 28, 2014 at 05:16:38PM +0100, Jan Alexander Steffens wrote:
On Oct 28, 2014 5:05 PM, Lennart Poettering lenn...@poettering.net
wrote:
On Tue, 28.10.14 11:28, Dale R. Worley (wor...@alum.mit.edu) wrote:
That is not entirely true. I'm a user (because systemd is in Fedora
19), and I've complained that if I mark an /etc/fstab entry as
nofail, some part of systemd will wait *forever* to see if the
partition becomes available, whereas the behavior that I want (which
was provided in earlier Fedora releases) is that once the system
gets to the point of user logins, it will give up on automatic booting
(and leave it to manual control).
I have already replied to this, and pointed out that such a scheme is
inherently racy, and that this is something we will unlikely support
natively in systemd. Sorry for that.
I think the actual issue here is the behavior of Type=idle, which delays
the gettys for an annoying amount of time.
Maybe launching the getty should shut off boot messages instead. Or maybe
this should happen after a configurable IdleTimeout instead of having
Type=idle always wait until end of transaction.
You mean like the code in execute.c does?
#define IDLE_TIMEOUT_USEC (5*USEC_PER_SEC)
...
r = fd_wait_for_event(idle_pipe[0], POLLHUP, IDLE_TIMEOUT_USEC);
if (idle_pipe[3] = 0 r == 0 /* timeout */) {
/* Signal systemd that we are bored and want to continue. */
;)
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysusers: Unconditional chown on /etc/{passwd, group, shadow, gshadow}? Is it sane?
On 28/10/14 16:34, Colin Guthrie wrote:
It seems we have different permissions for /etc/{g}shadow than fedora.
We don't package it as ,root,root but rather 0440,root,shadow.
Who is we? Mageia? FYI, Debian uses 0640 root:shadow for the same files.
We can then run some tools that need direct access as setgid rather than
full blown setuid. I'm not totally convinced of the security benefits
here (and I think actually 0440 is buggy for a setgid tool like chage -
I'd have thought it would need to be 0660 to actually change the age,
but I digress).
In Debian, the policy is that members of group shadow may read the
shadow password files (so that, given a typed-in password, they may
check whether it matches the stored hashed password) but only uid 0 may
write those files. Your file permissions seem consistent with that
policy; your distro is probably relying on setuid-root tools being able
to ignore the lack of read permission because they also get
CAP_DAC_OVERRIDE.
S
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv3] core: send sigabrt on watchdog timeout to get the stacktrace
On Tue, 28.10.14 16:35, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:
Applied! Thanks!
if sigabrt doesn't do the job, follow regular shutdown
routine, sigterm sigkill.
---
TODO| 2 --
man/systemd.service.xml | 5 +++--
src/core/busname.c | 2 +-
src/core/mount.c| 3 ++-
src/core/scope.c| 2 +-
src/core/service.c | 37 ++---
src/core/service.h | 1 +
src/core/socket.c | 3 ++-
src/core/swap.c | 3 ++-
src/core/unit.c | 24 ++--
src/core/unit.h | 8 +++-
11 files changed, 63 insertions(+), 27 deletions(-)
diff --git a/TODO b/TODO
index acac4e3..3e85eee 100644
--- a/TODO
+++ b/TODO
@@ -54,8 +54,6 @@ Features:
* consider showing the unit names during boot up in the status output, not
just the unit descriptions
-* send SIGABRT when a service watchdog is triggered, by default, so that we
acquire a backtrace of the hang.
-
* dhcp: do we allow configuring dhcp routes on interfaces that are not the
one we got the dhcp info from?
* maybe allow timer units with an empty Units= setting, so that they
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 115d169..e563b19 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -593,8 +593,9 @@
(i.e. the keep-alive ping). If the time
between two such calls is larger than
the configured time, then the service
-is placed in a failed state. By
-setting varnameRestart=/varname to
+is placed in a failed state and it will
+be terminated with
varnameSIGABRT/varname.
+By setting varnameRestart=/varname to
optionon-failure/option or
optionalways/option, the service
will be automatically restarted. The
diff --git a/src/core/busname.c b/src/core/busname.c
index 22d2a6d..68cb6ca 100644
--- a/src/core/busname.c
+++ b/src/core/busname.c
@@ -446,7 +446,7 @@ static void busname_enter_signal(BusName *n, BusNameState
state, BusNameResult f
r = unit_kill_context(UNIT(n),
kill_context,
- state != BUSNAME_SIGTERM,
+ state != BUSNAME_SIGTERM ? KILL_KILL :
KILL_TERMINATE,
-1,
n-control_pid,
false);
diff --git a/src/core/mount.c b/src/core/mount.c
index e284357..01243c3 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -775,7 +775,8 @@ static void mount_enter_signal(Mount *m, MountState
state, MountResult f) {
r = unit_kill_context(
UNIT(m),
m-kill_context,
-state != MOUNT_MOUNTING_SIGTERM state !=
MOUNT_UNMOUNTING_SIGTERM state != MOUNT_REMOUNTING_SIGTERM,
+(state != MOUNT_MOUNTING_SIGTERM state !=
MOUNT_UNMOUNTING_SIGTERM state != MOUNT_REMOUNTING_SIGTERM) ?
+KILL_KILL : KILL_TERMINATE,
-1,
m-control_pid,
false);
diff --git a/src/core/scope.c b/src/core/scope.c
index e8f9e8d..0f7c1f9 100644
--- a/src/core/scope.c
+++ b/src/core/scope.c
@@ -243,7 +243,7 @@ static void scope_enter_signal(Scope *s, ScopeState
state, ScopeResult f) {
r = unit_kill_context(
UNIT(s),
s-kill_context,
-state != SCOPE_STOP_SIGTERM,
+state != SCOPE_STOP_SIGTERM ? KILL_KILL :
KILL_TERMINATE,
-1, -1, false);
if (r 0)
goto fail;
diff --git a/src/core/service.c b/src/core/service.c
index d160c4e..2b16778 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -56,6 +56,7 @@ static const UnitActiveState
state_translation_table[_SERVICE_STATE_MAX] = {
[SERVICE_EXITED] = UNIT_ACTIVE,
[SERVICE_RELOAD] = UNIT_RELOADING,
[SERVICE_STOP] = UNIT_DEACTIVATING,
+[SERVICE_STOP_SIGABRT] = UNIT_DEACTIVATING,
[SERVICE_STOP_SIGTERM] = UNIT_DEACTIVATING,
[SERVICE_STOP_SIGKILL] = UNIT_DEACTIVATING,
[SERVICE_STOP_POST] = UNIT_DEACTIVATING,
@@ -76,6 +77,7 @@ static const UnitActiveState
state_translation_table_idle[_SERVICE_STATE_MAX] =
[SERVICE_EXITED] = UNIT_ACTIVE,
[SERVICE_RELOAD] = UNIT_RELOADING,
[SERVICE_STOP] = UNIT_DEACTIVATING,
+
[systemd-devel] starting Oracle with systemd
Is this the best way to start Oracle?
[root@localhost system]# cat oracle-foo.service
[Unit]
Description=oracle db - foo
After=syslog.target
[Service]
Environment=ORACLE_SID=foo ORACLE_HOME=/home/oracle/Ora12c/db
ExecStart=/bin/ksh -c 'print connect / as sysdba \n startup \n quit |
$ORACLE_HOME/bin/sqlplus -silent /nolog'
ExecStop=/bin/ksh -c 'print connect / as sysdba \n shutdown immediate \n quit
| $ORACLE_HOME/bin/sqlplus -silent /nolog'
Type=forking
User=oracle
Group=dba
[Install]
WantedBy=multi-user.target
#This file should be placed in /etc/systemd/system
#enable for start at boot by: systemctl enable oracle_db-foo.service
I used to do it with an init.d script that grabbed the SID out of argv[0] with
ORACLE_SID=${0##*-} - I'm assuming that a systemd service file can't grab
anything similarly out of argv[0], and I can't hard-link them all together.
I may have several instances on a machine; I'd like one service to start/stop
everything if possible (maybe with dbstart/dbshut), but I also want granular
control over each Oracle instance.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] starting Oracle with systemd
On 10/28/2014 07:08 PM, Fisher, Charles J. (Top Echelon) wrote: Is this the best way to start Oracle? No and unfortunately for you Oracle is not open source and has a bad track record taking code submissions which is probably why nobody has written a proper systemd unit for it and pushed it upstream. snip ( you need to post to the original initscript along with any startup scripts in conjuction with that init script to so the proper course of action can be taken when migrating it to native systemd unit(s) use something like fpaste if you intent on doing that ) I may have several instances on a machine; I’d like one service to start/stop everything if possible (maybe with dbstart/dbshut), but I also want granular control over each Oracle instance. You would do so by creating an specific oracledb.target followed by new oracle instance units. I'm not sure how much we should be involved with migrating that since it's closed source and we cant be held countable if our migration breaks your support contract hence it's probably best that you requesting new units and targets from Oracle support directly. ( which is probably not what you want to hear but meh ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
El mar, 28-10-2014 a las 17:05 +0100, Lennart Poettering escribió: [...] http://lists.freedesktop.org/archives/systemd-devel/2014-October/024325.html Looks interesting. Have you think in having some kind of wiki or page listing this kind of tricks to solve things like that. That way we prevent people from applying many different solutions that could have different drawbacks and also have them in a place a bit more easily accessible Thanks a lot ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] starting Oracle with systemd
Interestingly, placing the Oracle database listener in its own service propagates this cgroup to all client connections into all databases. Stopping the listener service kills these connections for all instances handled by the listener, which is not the normal/expected behavior. [root@localhost system]# psc | grep lsnr 8619 oracle 1:name=systemd:/system.slic /home/oracle/Ora12c/db/bin/tnslsnr LISTENER -inherit [root@localhost system]# ps xawf -eo args,cgroup | tail … ora_q002_orcl 1:name=systemd:/system.slice/oracle-orcl.service ora_q003_orcl 1:name=systemd:/system.slice/oracle-orcl.service oracleorcl (LOCAL=NO) 1:name=systemd:/system.slice/oracle-listener.service ora_j000_orcl 1:name=systemd:/system.slice/oracle-orcl.service ora_j001_orcl 1:name=systemd:/system.slice/oracle-orcl.service The dbstart script (supplied by Oracle) also likely should not be used, since it will place all instances in the same cgroup. From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Jóhann B. Guðmundsson Sent: Tuesday, October 28, 2014 2:43 PM To: systemd-devel@lists.freedesktop.org Subject: EXT: Re: [systemd-devel] starting Oracle with systemd On 10/28/2014 07:08 PM, Fisher, Charles J. (Top Echelon) wrote: Is this the best way to start Oracle? No and unfortunately for you Oracle is not open source and has a bad track record taking code submissions which is probably why nobody has written a proper systemd unit for it and pushed it upstream. snip ( you need to post to the original initscript along with any startup scripts in conjuction with that init script to so the proper course of action can be taken when migrating it to native systemd unit(s) use something like fpaste if you intent on doing that ) I may have several instances on a machine; I’d like one service to start/stop everything if possible (maybe with dbstart/dbshut), but I also want granular control over each Oracle instance. You would do so by creating an specific oracledb.target followed by new oracle instance units. I'm not sure how much we should be involved with migrating that since it's closed source and we cant be held countable if our migration breaks your support contract hence it's probably best that you requesting new units and targets from Oracle support directly. ( which is probably not what you want to hear but meh ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev: Add hidraw_id and a rule file to invoke it
So far, hidraw_id detects U2F tokens and sets:
ID_U2F_TOKEN=1
ID_SECURITY_TOKEN=1
This causes the uaccess rules to apply to U2F devices.
---
I've never written any udev code before. Feedback welcome.
If you think this doesn't belong in udev, I can try to find it another home.
.gitignore | 1 +
Makefile.am| 11
rules/60-hidraw.rules | 7 ++
src/udev/hidraw_id/Makefile| 1 +
src/udev/hidraw_id/hidraw_id.c | 144 +
5 files changed, 164 insertions(+)
create mode 100644 rules/60-hidraw.rules
create mode 12 src/udev/hidraw_id/Makefile
create mode 100644 src/udev/hidraw_id/hidraw_id.c
diff --git a/.gitignore b/.gitignore
index f119b574c777..4bd3cdf08f0d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -34,6 +34,7 @@
/exported
/exported-*
/gtk-doc.make
+/hidraw_id
/hostnamectl
/install-tree
/journalctl
diff --git a/Makefile.am b/Makefile.am
index fae946a388af..9f64687d32b1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3542,6 +3542,17 @@ udevlibexec_PROGRAMS += \
ata_id
#
--
+hidraw_id_SOURCES = \
+ src/udev/hidraw_id/hidraw_id.c
+
+hidraw_id_LDADD = \
+ libudev-internal.la \
+ libsystemd-shared.la
+
+udevlibexec_PROGRAMS += \
+ hidraw_id
+
+#
--
cdrom_id_SOURCES = \
src/udev/cdrom_id/cdrom_id.c
diff --git a/rules/60-hidraw.rules b/rules/60-hidraw.rules
new file mode 100644
index ..1ee9c812f711
--- /dev/null
+++ b/rules/60-hidraw.rules
@@ -0,0 +1,7 @@
+# do not edit this file, it will be overwritten on update
+
+ACTION==remove, GOTO=hidraw_end
+
+SUBSYSTEM==hidraw, IMPORT{program}=hidraw_id --udev
+
+LABEL=keyboard_end
diff --git a/src/udev/hidraw_id/Makefile b/src/udev/hidraw_id/Makefile
new file mode 12
index ..d0b0e8e0086f
--- /dev/null
+++ b/src/udev/hidraw_id/Makefile
@@ -0,0 +1 @@
+../Makefile
\ No newline at end of file
diff --git a/src/udev/hidraw_id/hidraw_id.c b/src/udev/hidraw_id/hidraw_id.c
new file mode 100644
index ..e32f222f22f9
--- /dev/null
+++ b/src/udev/hidraw_id/hidraw_id.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) Andrew Lutomirski, 2014
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include stdio.h
+#include string.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include unistd.h
+
+#include libudev.h
+#include libudev-private.h
+
+_printf_(6,0)
+static void log_fn(struct udev *udev, int priority,
+ const char *file, int line, const char *fn,
+ const char *format, va_list args)
+{
+log_metav(priority, file, line, fn, format, args);
+}
+
+int main(int argc, char **argv)
+{
+struct udev *udev;
+struct udev_device *dev, *hiddev;
+char path[4096];
+unsigned char desc[4096];
+int desclen;
+int fd = -1;
+int i;
+int ret = 1;
+unsigned int usage_page = 0;
+int is_u2f_token = 0;
+
+if (argc != 2) {
+fprintf(stderr, Usage: hidraw_id SYSFS_PATH|--udev\n);
+return 1;
+}
+
+log_parse_environment();
+log_open();
+
+udev = udev_new();
+
+udev_set_log_fn(udev, log_fn);
+
+if (!strcmp(argv[1], --udev))
+dev = udev_device_new_from_environment(udev);
+else
+dev = udev_device_new_from_syspath(udev, argv[1]);
+
+if (!dev)
+goto out;
+
+hiddev = udev_device_get_parent(dev);
+if (!hiddev)
+goto out;
+
+if (snprintf(path, sizeof(path), %s/report_descriptor,
+ udev_device_get_syspath(hiddev)) (int)sizeof(path))
+return 1;
+
+fd = open(path, O_RDONLY | O_NOFOLLOW);
+if (fd == -1)
+goto out;
+
+desclen = read(fd, desc, sizeof(desc));
+if (desclen = 0)
+goto out;
+
+/* Parse the report descriptor. */
+for (i = 0; i desclen; ) {
+unsigned char tag = desc[i] 4;
+unsigned char type = (desc[i] 2) 0x3;
+unsigned char sizecode = desc[i] 0x3;
+int size, j;
[systemd-devel] Luks + lvm in initrd
Hi, I'm going on with my work to have systemd in initrd on NixOS (using dracut is a little complicated at the moment). Everything works fine, I've ported luks and lvm and both work separately. However I'm hitting a problem when using luks and lvm on top of luks. SETUP Software: systemd 212, lvm 2.02.111, cryptsetup 1.6.3, kernel 3.14.22 The test is done with kvm. I have a device /dev/vda formatted with luks which gets opened in /dev/mapper/luksroot. Then lvm with a vg named vg and an lv named lv so that it gets named /dev/mapper/vg-lv. I have a sysroot.mount What=/dev/mapper/vg-lv and requires/after the cryptsetup service. The cryptsetup service runs systemd-cryptsetup attach luksroot /dev/vda. All fine, the luks gets opened correctly etc. PROBLEM Note I don't do any vgchange -a y, in any service, in any script. The /dev/vda appears, and then cryptsetup service runs. Luks is unlocked, /dev/mapper/luksroot and systemd tries to mount sysroot.mount. This is the problem, systemd does not wait for /dev/mapper/vg-lv to appear before mounting sysroot. In fact, it does not exist at all. It's like luksOpen + some udev rule tell udev/systemd that the device is there, but it's not. Note: if I disable the cryptsetup service, sysroot.mount correctly waits for /dev/mapper/vg-lv to appear. So the setup is pretty simple, I've read the udev rules however they're a little complex for my poor knowledge. The udev rules installed are all of lvm, dm. From systemd/udev it's: 60-cdrom_id.rules 60-persistent-storage.rules 80-drivers.rules 99-systemd.rules Any hints on where the culprit can be? Same happens with lvmetad. Best regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] kernel-install/90-loaderentry.install: fix cmdline parsing
A recent commit (2f3a215) changed the parsing of /proc/cmdline to use a
shell array. Unfortunately, this introduced a bug: read -ar line
populates the shell variable $r, not $line. This breaks installation of
new loader entries:
# kernel-install add 3.17.1-304.fc21.x86_64 \
/boot/vmlinuz-3.17.1-304.fc21.x86_64
Could not determine the kernel command line parameters.
Please specify the kernel command line in /etc/kernel/cmdline!
This commit alters the read command to correctly populate the $line
array instead.
Signed-off-by: Michael Chapman m...@very.puzzling.org
---
src/kernel-install/90-loaderentry.install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/kernel-install/90-loaderentry.install
b/src/kernel-install/90-loaderentry.install
index 6f032b5..d433e00 100644
--- a/src/kernel-install/90-loaderentry.install
+++ b/src/kernel-install/90-loaderentry.install
@@ -47,7 +47,7 @@ if [[ -f /etc/kernel/cmdline ]]; then
fi
if ! [[ ${BOOT_OPTIONS[*]} ]]; then
-read -ar line /proc/cmdline
+read -a line -r /proc/cmdline
for i in ${line[@]}; do
[[ ${i#initrd=*} != $i ]] continue
BOOT_OPTIONS[${#BOOT_OPTIONS[@]}]=$i
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] starting Oracle with systemd
В Tue, 28 Oct 2014 15:08:45 -0400
Fisher, Charles J. (Top Echelon) charles.fis...@alcoa.com пишет:
Is this the best way to start Oracle?
[root@localhost system]# cat oracle-foo.service
[Unit]
Description=oracle db - foo
After=syslog.target
[Service]
Environment=ORACLE_SID=foo ORACLE_HOME=/home/oracle/Ora12c/db
ExecStart=/bin/ksh -c 'print connect / as sysdba \n startup \n quit |
$ORACLE_HOME/bin/sqlplus -silent /nolog'
ExecStop=/bin/ksh -c 'print connect / as sysdba \n shutdown immediate \n
quit | $ORACLE_HOME/bin/sqlplus -silent /nolog'
Type=forking
User=oracle
Group=dba
[Install]
WantedBy=multi-user.target
#This file should be placed in /etc/systemd/system
#enable for start at boot by: systemctl enable oracle_db-foo.service
I used to do it with an init.d script that grabbed the SID out of argv[0]
with ORACLE_SID=${0##*-} - I'm assuming that a systemd service file can't
grab anything similarly out of argv[0], and I can't hard-link them all
together.
You can create template unit and simply start every instance as
oracle@foo.service (you do not even need to symlink it - it will be
instantiated on the fly).
I may have several instances on a machine; I'd like one service to start/stop
everything if possible (maybe with dbstart/dbshut), but I also want granular
control over each Oracle instance.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
