Re: [systemd-devel] [ANNOUNCE] systemd 203
2013/5/7 Lennart Poettering lenn...@poettering.net: * libsystemd-logind.so gained a new call sd_get_machine_names() to enumerate running containers and VMs (currently only supported by very new libvirt and nspawn). sd_login_monitor can now be used to watch VMs/containers coming and going. Looks like this is broken. The library does not actually export that symbol. This is due to a missing _public_ in [1] Cheers, Michael [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/login/sd-login.c#n594 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] wake from sleep on systemd timer
On Tue, May 07, 2013 at 12:10:26AM +0200, Kai Krakow wrote: [...] Meanwhile, where's a good place to contribute my systemd unit files I created for different services that not yet seem to be covered by the systemd distribution? They could also need some review maybe... Upstream - submit the patches to developers of such services. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user instance
On 05/06/2013 10:14 PM, Kai Krakow wrote: Jóhann B. Guðmundsson johan...@gmail.com schrieb: But now I want to (and need to) give some users cron-like abilities. I discovered that systemd supports user instances - perfect! Then install cronie... That's the obvious solution but a little bit counter-productive with respect to my question... Systemd is not ready for users cron like behavior. Not from a usability perspective ( complexity of time units vs cron's one liner ) and from the fact that there are cron features which cannot be support ( for now ) and of those that will not be supported. I threw some ideas out there on the table in brno but how we might try to solve that ( from an user usability perspective ) but to do so, along with supporting few other things in the future like container ( startup ) templates and the fact that the drop-in snippets in .d/*.conf does not scale very well ( due to it's own unit directory implementation ) I'm afraid we will need to rethink and reconstruct /etc/systemd/ directory structure sooner rather then later since it's slowly becoming too complex and ill manageable in the process. Anyway basically just think of systemd timer units cron like implementation like systemd's (x)inetd replacement which only replaces it up to 80% - 90% JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-cgroups-agent failed to get dbus connection
Hi, I have noticed sometimes during shutdown, the following message appears on screen twice: systemd-cgroups-agent failed to get dbus connection: failed to connect to socket /org/freedesktop/systemd/private connection refused The following may be relevant from the logs: May 07 09:13:05 hobo login[223]: pam_unix(login:session): session closed for user ross May 07 09:13:05 hobo login[223]: pam_systemd(login:session): Failed to connect to system bus: Did not reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. May 07 09:13:05 hobo systemd[1]: Stopped Getty on tty1. Seems harmless enough, but there could be some sort of bug here. -- Ross Lagerwall ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 203
'Twas brillig, and Lennart Poettering at 07/05/13 01:41 did gyre and gimble: This is probably a good release to synchronize a distribution on. For example, it is our goal that this is the version we will include in Fedora 19, more or less. You said that about 195 and then promptly shipped newer versions in Fedora there after - ourselves and suse listened to that previous advice any synchronised on that version for the ease of maintainability, but that was somewhat scuppered when newer versions showed up in Fedora instead. Such is the way of life, but by the sounds of upcoming changes, it looks like you might genuinely stick with 203 this time :p Either way, good work :) 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
Re: [systemd-devel] [ANNOUNCE] systemd 203
On Tue, 07.05.13 06:36, Michael Biebl (mbi...@gmail.com) wrote: 2013/5/7 Lennart Poettering lenn...@poettering.net: * libsystemd-logind.so gained a new call sd_get_machine_names() to enumerate running containers and VMs (currently only supported by very new libvirt and nspawn). sd_login_monitor can now be used to watch VMs/containers coming and going. Looks like this is broken. The library does not actually export that symbol. This is due to a missing _public_ in [1] Ah indeed! Fixed in git! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 203
On Tue, 07.05.13 09:53, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Lennart Poettering at 07/05/13 01:41 did gyre and gimble: This is probably a good release to synchronize a distribution on. For example, it is our goal that this is the version we will include in Fedora 19, more or less. You said that about 195 and then promptly shipped newer versions in Fedora there after - ourselves and suse listened to that previous advice any synchronised on that version for the ease of maintainability, but that was somewhat scuppered when newer versions showed up in Fedora instead. Such is the way of life, but by the sounds of upcoming changes, it looks like you might genuinely stick with 203 this time :p Either way, good work :) Well it's only our goal to make this the release for F19. But revisiting this I might actually quickly roll 204 to correctthe exporting issue... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 203
On 05/07/2013 08:53 AM, Colin Guthrie wrote: 'Twas brillig, and Lennart Poettering at 07/05/13 01:41 did gyre and gimble: This is probably a good release to synchronize a distribution on. For example, it is our goal that this is the version we will include in Fedora 19, more or less. You said that about 195 and then promptly shipped newer versions in Fedora there after - ourselves and suse listened to that previous advice any synchronised on that version for the ease of maintainability, but that was somewhat scuppered when newer versions showed up in Fedora instead. Such is the way of life, but by the sounds of upcoming changes, it looks like you might genuinely stick with 203 this time :p Either way, good work :) Col Lennart does not manage systemd in GA releases of Fedora, Michal Schmidt does ( and is doing a great job doing so ) In F18 we are currently shipping 201 with 52 patches... |# Back out incompatibilities in F18: Patch0001: 0001-F18-units-don-t-always-use-sulogin-in-rescue.service.patch Patch0002: 0002-F18-Revert-service-sysv-remove-distribution-specific.patch Patch0003: 0003-F18-re-add-http-daemon.target.patch Patch0004: 0004-F18-bring-back-single.service.patch Patch0005: 0005-F18-Revert-udev-network-device-renaming-immediately-.patch Patch0006: 0006-F18-explain-what-happened-to-systemctl-dot.patch Patch0007: 0007-F18-Make-predictable-net-names-opt-in-instead-of-opt.patch # Selected post-v201 patches from upstream: Patch0008: 0008-keymap-Add-HP-EliteBook-8460p.patch Patch0009: 0009-keymap-Fix-typo-in-previous-commit.patch Patch0010: 0010-shutdown-print-a-nice-message-before-returning-to-in.patch Patch0011: 0011-units-fix-some-left-over-mentions-of-remote-fs-setup.patch Patch0012: 0012-logind-avoid-creating-stale-session-state-files.patch # Simple workaround for dracut difference vs F19 Patch0013: 0013-F18-main-downgrade-message-about-failure-to-isolate-.patch Patch0014: 0014-fileio-in-envfiles-do-not-skip-lines-following-empty.patch # Workaround some broken unit files in F18 Patch0015: 0015-F18-ship-a-dummy-syslog.target.patch Patch0016: 0016-journal-fix-broken-tags-_SOURCE_REALTIME_TIMESTAMP-a.patch Patch0017: 0017-do-not-change-console-to-non-unicode-for-LANG-C.patch Patch0018: 0018-journal-fix-off-by-one-error-in-native-message-iovec.patch Patch0019: 0019-core-device.c-fix-possible-segfault.patch # Avoid change in sysctl.d precedence behaviour Patch0020: 0020-F18-sysctl-give-files-with-later-names-precedence-ov.patch Patch0021: 0021-cryptsetup-set-the-timeout-to-0-by-default.patch Patch0022: 0022-man-document-that-timeout-0-is-the-default-for-entri.patch Patch0023: 0023-cryptsetup-generator-add-support-for-rd.luks.key.patch Patch0024: 0024-crypt-setup-generator-correctly-check-return-of-strd.patch Patch0025: 0025-logind-dbus-initialize-result-variable.patch Patch0026: 0026-nss-myhostname-ensure-that-glibc-s-assert-is-used.patch Patch0027: 0027-build-sys-prevent-library-underlinking.patch Patch0028: 0028-hwdb-update.patch Patch0029: 0029-hwdb-update.patch Patch0030: 0030-hwdb-update.patch Patch0031: 0031-conf-parser-generate-7-parsing-functions-from-a-macr.patch Patch0032: 0032-core-main-generate-4-parsing-functions-from-a-macro.patch Patch0033: 0033-Report-about-syntax-errors-with-metadata.patch Patch0034: 0034-core-let-s-make-our-log-messages-proper-sentences-wi.patch Patch0035: 0035-core-log-a-few-more-things-under-UNIT.patch Patch0036: 0036-Move-bus_error-to-dbus-common-and-remove-bus_error_m.patch Patch0037: 0037-unit-rework-trigger-dependency-logic.patch Patch0038: 0038-timer-make-sure-we-restart-timers-even-if-units-are-.patch Patch0039: 0039-logind-don-t-busy-loop-if-a-job-is-still-running-but.patch Patch0040: 0040-core-remove-duplicate-MESSAGE-from-log-message.patch Patch0041: 0041-man-clarify-what-Restart-means.patch Patch0042: 0042-man-improve-documentation-for-specifiers.patch Patch0043: 0043-dbus-execute-fix-introspection.patch Patch0044: 0044-unit-rework-stop-pending-logic.patch Patch0045: 0045-core-bump-simultaneous-bus-connection-limit-to-512.patch Patch0046: 0046-hwdb-update.patch Patch0047: 0047-core-unit_inactive_or_pending-should-actually-do-as-.patch Patch0048: 0048-man-correct-SIGUSR1-semantics-for-journald.patch Patch0049: 0049-man-clarify-behaviour-of-Also-in-unit-files.patch Patch0050: 0050-man-fix-typos-in-systemd.special.patch Patch0051: 0051-core-escape-unit-name-from-udev.patch Patch0052: 0052-journald-be-more-careful-when-we-try-to-flush-the-ru.patch | Yeah sure 50 patches ain't much and starts out easy enough but inevitably as time goes on it becomes increasingly difficult to maintain ( such is the nature of these things ) so hopefully things start to settled down in systemd so we can
Re: [systemd-devel] Masking systemd-journal-flush and setting journal storage to persistent
Hi, No worries. Maybe you want to add systemd-journal-flush.service to man systemd-journald. Maybe altering the help text as following too: To make the data persistent it is sufficient to create /var/log/journal/ where systemd-journald-flush.service will then store the data. On Mon, May 6, 2013 at 10:40 PM, Lennart Poettering lenn...@poettering.netwrote: On Mon, 06.05.13 22:39, Lennart Poettering (lenn...@poettering.net) wrote: According to man journald, it shouldn't be necessary to send the SIGUSR1 as systemd-journal-flush.service does. It was my expectation that systemd would eventually carry journal to /var/. The man page is actually incorrect here. We changed that a while back from the implicit flush to an explicit flush to get rid of some races. I have fixed the man page now. Sorry for the confusion. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] condition, man: Add support for ConditionSecurity=smack
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 49103da..256c813 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -984,8 +984,9 @@
may be used to check whether the given
security module is enabled on the
system. Currently the only recognized
-values are varnameselinux/varname
-and varnameapparmor/varname.
+values are varnameselinux/varname,
+varnameapparmor/varname and
+varnamesmack/varname.
The test may be negated by prepending
an exclamation
mark./para
diff --git a/src/core/condition.c b/src/core/condition.c
index 4aa5530..16cae6d 100644
--- a/src/core/condition.c
+++ b/src/core/condition.c
@@ -164,6 +164,8 @@ static bool test_security(const char *parameter) {
#endif
if (streq(parameter, apparmor))
return access(/sys/kernel/security/apparmor/, F_OK) == 0;
+ if (streq(parameter, smack))
+ return access(/sys/fs/smackfs, F_OK) == 0;
return false;
}
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] condition, man: Add support for ConditionSecurity=smack
On Tue, 07.05.13 13:21, Karol Lewandowski (k.lewando...@samsung.com) wrote:
Heya,
Hmm, does that directory always exist? Or only if AppArmor is actually
runtime enabled?
I.e. this check should ideally only return true if SMACK is not only
built into the kernel, but actually really enabled during
runtime. That's what the SELinux check does and what the most useful
semantics are.
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 49103da..256c813 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -984,8 +984,9 @@
may be used to check whether the given
security module is enabled on the
system. Currently the only recognized
-values are varnameselinux/varname
-and varnameapparmor/varname.
+values are varnameselinux/varname,
+varnameapparmor/varname and
+varnamesmack/varname.
The test may be negated by prepending
an exclamation
mark./para
diff --git a/src/core/condition.c b/src/core/condition.c
index 4aa5530..16cae6d 100644
--- a/src/core/condition.c
+++ b/src/core/condition.c
@@ -164,6 +164,8 @@ static bool test_security(const char *parameter) {
#endif
if (streq(parameter, apparmor))
return access(/sys/kernel/security/apparmor/, F_OK) == 0;
+ if (streq(parameter, smack))
+ return access(/sys/fs/smackfs, F_OK) == 0;
return false;
}
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Any movement on adding a pid indicator for setroubleshoot to add to the journal entry.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Really would like to be able to track an alert back to the causing pid. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGI7dgACgkQrlYvE4MpobMxgACgpFVhYWfQiy5fABCzKLzzYqUb /swAoONAcKkF74MV9LpQZNGjrcRCIZvj =VYzt -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Start ctrl-alt-del.target irreversibly
This makes ctrl-alt-del reboots more robust, just like systemctl
reboot.
---
src/core/manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index c7f8f20..0508628 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -1372,7 +1372,7 @@ static int manager_process_signal_fd(Manager *m) {
case SIGINT:
if (m-running_as == SYSTEMD_SYSTEM) {
-manager_start_target(m,
SPECIAL_CTRL_ALT_DEL_TARGET, JOB_REPLACE);
+manager_start_target(m,
SPECIAL_CTRL_ALT_DEL_TARGET, JOB_REPLACE_IRREVERSIBLY);
break;
}
--
1.8.2.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Any movement on adding a pid indicator for setroubleshoot to add to the journal entry.
On Tue, May 7, 2013 at 2:04 PM, Daniel J Walsh dwa...@redhat.com wrote: Really would like to be able to track an alert back to the causing pid. You mean the: * introduce generic AUGMENT_PID=, AUGMENT_DEVICE= fields item in the TODO list, right? A facility that one process can submit information really belonging to another one, to the journal. In your case the setroubleshoot PID logs something about the apache service, and if we query the status of apache we get that setroubleshoot logs along with the logs that originated from apache, right? How do we handle the trust here? Allow that augmentation only for privileged processes? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Any movement on adding a pid indicator for setroubleshoot to add to the journal entry.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2013 08:22 AM, Kay Sievers wrote: On Tue, May 7, 2013 at 2:04 PM, Daniel J Walsh dwa...@redhat.com wrote: Really would like to be able to track an alert back to the causing pid. You mean the: * introduce generic AUGMENT_PID=, AUGMENT_DEVICE= fields item in the TODO list, right? A facility that one process can submit information really belonging to another one, to the journal. In your case the setroubleshoot PID logs something about the apache service, and if we query the status of apache we get that setroubleshoot logs along with the logs that originated from apache, right? How do we handle the trust here? Allow that augmentation only for privileged processes? Kay Yes I would only allow priv processes to do this, I guess eventually we could add an SELinux check to this and maybe a capability check like, CAP_SYSLOG? But for now, just check that the UID==0 of the process doing an AUGMENT_PID. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGI9PwACgkQrlYvE4MpobMqVwCeIf5WDUy/HX1Ft2o8GFlZYaza t/wAmgPTn+EX6h8PYGcR9tYuZjRjVeI2 =WW6I -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] condition, man: Add support for ConditionSecurity=smack
On 05/07/2013 01:32 PM, Lennart Poettering wrote:
On Tue, 07.05.13 13:21, Karol Lewandowski (k.lewando...@samsung.com) wrote:
Heya,
Hmm, does that directory always exist? Or only if AppArmor is actually
runtime enabled?
/sys/fs/smackfs is only registered when smack lsm is actually enabled:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/smack/smackfs.c?id=e93072374112db9dc86635934ee761249be28370#n2179
I.e. this check should ideally only return true if SMACK is not only
built into the kernel, but actually really enabled during
runtime. That's what the SELinux check does and what the most useful
semantics are.
Ok, I see that libselinux will consider selinux to be disabled also when
policy is not loaded:
http://userspace.selinuxproject.org/trac/browser/libselinux/src/enabled.c#L12
I guess we could do something similar (inspect /proc/self/attr/current)
but honestly, I don't think it's really needed. Rafał, could you correct me
if I'm wrong?
Cheers
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 49103da..256c813 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -984,8 +984,9 @@
may be used to check whether the given
security module is enabled on the
system. Currently the only recognized
-values are varnameselinux/varname
-and varnameapparmor/varname.
+values are varnameselinux/varname,
+varnameapparmor/varname and
+varnamesmack/varname.
The test may be negated by prepending
an exclamation
mark./para
diff --git a/src/core/condition.c b/src/core/condition.c
index 4aa5530..16cae6d 100644
--- a/src/core/condition.c
+++ b/src/core/condition.c
@@ -164,6 +164,8 @@ static bool test_security(const char *parameter) {
#endif
if (streq(parameter, apparmor))
return access(/sys/kernel/security/apparmor/, F_OK) == 0;
+if (streq(parameter, smack))
+return access(/sys/fs/smackfs, F_OK) == 0;
return false;
}
Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user instance
Kok, Auke-jan H auke-jan.h@intel.com schrieb: [Service] User=%I PAMName=systemd-shared ^^ this line is the cause of your problems, as the /etc/pam.d/systemd-shared file does not exist. I thought this is virtually profided by pam_systemd.so? But I may try your suggestion. Regards, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user instance
Jóhann B. Guðmundsson johan...@gmail.com schrieb: But now I want to (and need to) give some users cron-like abilities. I discovered that systemd supports user instances - perfect! Then install cronie... That's the obvious solution but a little bit counter-productive with respect to my question... Systemd is not ready for users cron like behavior. Okay... Well, I did not expect a full replacement anyway. But... Not from a usability perspective ( complexity of time units vs cron's one liner ) and from the fact that there are cron features which cannot be support ( for now ) and of those that will not be supported. True... I threw some ideas out there on the table in brno but how we might try to solve that ( from an user usability perspective ) but to do so, along with supporting few other things in the future like container ( startup ) templates and the fact that the drop-in snippets in .d/*.conf does not scale very well ( due to it's own unit directory implementation ) I'm afraid we will need to rethink and reconstruct /etc/systemd/ directory structure sooner rather then later since it's slowly becoming too complex and ill manageable in the process. Yes, it looks a bit messy there but it is maintainable for me. Anyway basically just think of systemd timer units cron like implementation like systemd's (x)inetd replacement which only replaces it up to 80% - 90% Sure. ...but: I just want some simple timers and just for a few users (maybe two or three) and these should be able to tear down the spawned process cleanly which cron really cannot do so well. The nice features from systemd as a simple (more or less) cron replacement are: * clean process teardown and keeping track of run-away processes * very good logging capabilities * easy to maintain cpu and io policies Actually it's meant to be used for an application server which has to spawn and watch background jobs every now and then and keep user-initiated services running. I don't think that can be done right with cron. At least we had our headaches with that in the past and here systemd seems to come in just right and handy. Thanks for an elaborated answer thou, I appreciate it. PS: I know that cron is the better tool for launching simple one-liners... Regards, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user instance
Well, actually the timers are a nice benefit only. We want to control user- initiated background-services for a web application server with this and cron hasn't been our best friend for this in the past. David Strauss da...@davidstrauss.net schrieb: I don't recommend spawning user instances of systemd just for their timer units to run. Each instance comes with a few MB of overhead, and you'll have no fun trying to spawn sessions in a way isolated from (but somehow integrated with) the PAM session initialization process. On Mon, May 6, 2013 at 3:14 PM, Kai Krakow hurikha...@gmail.com wrote: Jóhann B. Guðmundsson johan...@gmail.com schrieb: But now I want to (and need to) give some users cron-like abilities. I discovered that systemd supports user instances - perfect! Then install cronie... That's the obvious solution but a little bit counter-productive with respect to my question... Anyway, one has to take that route if everything else fails. Regards, Kai ___ 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] journalctl v202, loop endlessly
On Tue, May 7, 2013 at 4:01 AM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:
El 05/05/13 13:17, Sébastien Luttringer escribió:
Hello,
journcalctl --no-pager or journalctl | cat produce enless content
by looping accross journal entries. The date in lines restart from the
beginning when the end is reached.
We have reports about this behaviour in openSUSE as well, the problem is
that I cannot reproduce it, even with your sample journal files..
Bizarre.
I'm able to reproduce the bug with the attached C code (from man 2
sd_journal_next) and the provided tarball.
I also built systemd from git tree (~ v203) and bug still occur.
With some profiling + tracing, I guess it comes from sd_journal_next
in src/journal/journalctl.c which never return 0.
So the following break condition is never true and the loop is infinite.
Some breakpoints in gdb shows a kind of switch between system.journal
and user-18136.journal files before printing each log lines before the
bug occur.
When we have looped, only one journal file is looked between entries.
I don't know if it's usefull.
(gdb) info breakpoints
16 breakpoint keep y 0x0042b4d7 in output_short at
src/shared/logs-show.c:292
stop only if strcmp(message, New session 6 of user seblu.) == 0
breakpoint already hit 5 times
17 breakpoint keep y 0x004136fa in
real_journal_next at src/journal/sd-journal.c:913
stop only if found
breakpoint already hit 24295 times
silent
print f-path
c
mai 05 17:08:49 achille.seblu.net named[274]: dumpstats complete
$32223 = 0x6556b0
/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/user-18136.journal
$32224 = 0x655ba0 /tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system.journal
mai 05 17:11:26 achille.seblu.net sshd[7372]: Accepted publickey for
seblu from 82.234.72.62 port 6239 ssh2
$32225 = 0x6556b0
/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/user-18136.journal
$32226 = 0x655ba0 /tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system.journal
mai 05 17:11:26 achille.seblu.net sshd[7372]: pam_unix(sshd:session):
session opened for user seblu by (uid=0)
$32227 = 0x6556b0
/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/user-18136.journal
$32228 = 0x655ba0 /tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system.journal
mai 05 17:11:26 achille.seblu.net systemd-logind[251]: New session 6
of user seblu.
---Type return to continue, or q return to quit---
Breakpoint 16, output_short (f=0x773172a0 _IO_2_1_stdout_,
j=0x63df40, mode=OUTPUT_SHORT, n_columns=118,
flags=OUTPUT_COLOR) at src/shared/logs-show.c:292
292if (flags OUTPUT_CATALOG)
(gdb)
Continuing.
$32229 = 0x6556b0
/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/user-18136.journal
mai 05 17:11:26 achille.seblu.net sshd[7374]: subsystem request for
sftp by user seblu
$32230 = 0x655950
/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~
-- Reboot --
avril 22 03:00:42 zeus.seblu.net systemd-logind[248]: Removed session 7.
$32231 = 0x655950
/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~
avril 22 03:01:00 zeus.seblu.net fcron[10414]: Job /usr/sbin/run-cron
/etc/cron.hourly started for user systab...0415)
$32232 = 0x655950
/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~
avril 22 03:01:02 zeus.seblu.net fcron[10414]: Job /usr/sbin/run-cron
/etc/cron.hourly completed
$32233 = 0x655950
/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~
avril 22 03:07:09 zeus.seblu.net named[8102]: received control channel
command 'reload'
$32234 = 0x655950
/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~
avril 22 03:07:09 zeus.seblu.net named[8102]: loading configuration
from '/etc/named.conf'
$32235 = 0x655950
/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~
avril 22 03:07:09 zeus.seblu.net named[8102]: reading built-in trusted
keys from file '/etc/bind.keys'
Cheers,
--
Sébastien Seblu Luttringer
https://www.seblu.net
GPG: 0x2072D77A
#include stdio.h
#include string.h
#include systemd/sd-journal.h
int main(int argc, char *argv[]) {
int r;
sd_journal *j;
r = sd_journal_open_directory(j, /tmp/toto/3d69b1d747744a53ac1c25b78eee2764, 0);
if (r 0) {
fprintf(stderr, Failed to open journal: %s\n, strerror(-r));
return 1;
}
SD_JOURNAL_FOREACH(j) {
const char *d;
size_t l;
r = sd_journal_get_data(j, MESSAGE, d, l);
if (r 0) {
fprintf(stderr, Failed to read message field: %s\n, strerror(-r));
continue;
}
printf(%.*s\n, (int) l, d);
}
sd_journal_close(j);
return 0;
}
___
systemd-devel mailing list
