Re: [systemd-devel] SSL handshake error from offlineimap when using systemd to initialize
Am 24.01.2018 um 08:13 schrieb Yubin Ruan: On Tue, Jan 23, 2018 at 04:10:10PM +0100, Lennart Poettering wrote: On Di, 23.01.18 09:09, Reindl Harald (h.rei...@thelounge.net) wrote: depeding on how your network is configured use "network.service" or "networkmanager.service" (or however the networkmanager service is called in detail, i don#t use it) Nope. Use "network-online.target" if you are looking for a generic unit to order after that is reached only after the network has been "configured" for the first time, for some vague definition of "configured", that is up to the networking implementation to fill with sense... Now I have these in the configuration file [Unit] Description=Sync mail Wants=network-online.target After=network.target network-online.target [Service] Type=oneshot ExecStart=/path/to/the/script TimeoutStartSec=1min30s [Install] WantedBy=default.target However the script is still broken at system startup. Hmm...I am using a Ubuntu 16.04LTS. I will post if there are any news AGAIN: how is your network started Lennart is *not* correct - at least on Fedora all the wait-online stuff don't work while "After=network.service" does when you still ue the cliassic network.service for a lot of obvious reasons [root@srv-rhsoft:~]$ cat /etc/rc.d/init.d/network #! /bin/bash # # network Bring up/down networking # # chkconfig: - 10 90 # description: Activates/Deactivates all network interfaces configured to \ # start at boot time. # ### BEGIN INIT INFO # Provides: $network # Should-Start: iptables ip6tables NetworkManager-wait-online NetworkManager $network-pre # Short-Description: Bring up/down networking # Description: Bring up/down networking ### END INIT INFO ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SSL handshake error from offlineimap when using systemd to initialize
Am 24.01.2018 um 09:59 schrieb Yubin Ruan: On Wed, Jan 24, 2018 at 08:57:18AM +0100, Reindl Harald wrote: Am 24.01.2018 um 08:13 schrieb Yubin Ruan: On Tue, Jan 23, 2018 at 04:10:10PM +0100, Lennart Poettering wrote: On Di, 23.01.18 09:09, Reindl Harald (h.rei...@thelounge.net) wrote: depeding on how your network is configured use "network.service" or "networkmanager.service" (or however the networkmanager service is called in detail, i don#t use it) Nope. Use "network-online.target" if you are looking for a generic unit to order after that is reached only after the network has been "configured" for the first time, for some vague definition of "configured", that is up to the networking implementation to fill with sense... Now I have these in the configuration file [Unit] Description=Sync mail Wants=network-online.target After=network.target network-online.target [Service] Type=oneshot ExecStart=/path/to/the/script TimeoutStartSec=1min30s [Install] WantedBy=default.target However the script is still broken at system startup. Hmm...I am using a Ubuntu 16.04LTS. I will post if there are any news AGAIN: how is your network started Lennart is *not* correct - at least on Fedora all the wait-online stuff don't work while "After=network.service" does when you still ue the cliassic network.service for a lot of obvious reasons well, then try "After=networking.service network-manager.service" despite what others saying about targets - iam dong the same with "After=network.service" on Fedora for some years on 30 production servers and it works just fine in fact we have "After=network.service systemd-networkd.service network-online.target" on any service which needs networking on Fedora and RHEL7 Below are /etc/init.d/networking and /etc/init.d/network-manager respectively. It seems that it is /etc/init.d/networking that is responsible for bringing up the network. ## # /etc/init.d/networking ## # /etc/init.d/network-manager ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald missing crash logs
On So, 21.01.18 19:53, Farzad Panahi (farzad.pan...@gmail.com) wrote: > > On Fr, 12.01.18 16:13, Farzad Panahi (farzad.pan...@gmail.com) wrote: > > > > > I am running Arch-ARM on RPi3. I have noticed when system crashes I > > cannot > > > find any related crash log in journal logs. > > > > What specifically is a "crash" supposed to mean? > > > > > Crash in my case means that the box becomes unresponsive. Meaning that I > cannot ssh to it anymore until it is power cycled. I do not know what is > happening to the box because there are no logs at the time of crash. Logs > start rolling after the reboot. Well, that sounds more like a "hang" than what I would call a "crash". Now depending on the nature of the hang this might have the effect that the whole system simply freezes, and if that happens, then the journal can't do a thing either anymore... > > delivered. I am not sure what "crash" is supposed to mean, but are you > > sure that at least one LOG_CRIT/LOG_ALERT/LOG_EMERG message is > > delivered to userspace about that? > > > I am not sure about that. I just assume if some critical issue is > happening such that it makes the system unresponsive, then there should be > high priority logs associated with it. Well, that really depends on the nature of the hang. if the kenrel just locks up, then userspace won't get scheduled anymore, and hence no userspace logger in this world would help you tracking this down... > So I think one of the following is happening: > a) no log is generated at the time of crash (I think this is > unlikely) > b) log is generated but does not reach journald > c) log reaches journald but journald does not get a chance to persist it > d) journald persists the log but somehow the log is corrupted and ignored > > I think scenario "c" is the most probable one in my case. So I just want to > confirm if kernel panics, then most probably I will not see any logs in my > log files? Is there a recommended workaround to debug such cases? This is not a journal-specific issue: had kernel lockups are hard to debug. Without direct console access you are in trouble. make sure to turn on all printk logging directlyto consoleto track things like that down... But at that point it's probably better to ask the kernel community for help... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SSL handshake error from offlineimap when using systemd to initialize
On Wed, Jan 24, 2018 at 08:57:18AM +0100, Reindl Harald wrote:
>
>
> Am 24.01.2018 um 08:13 schrieb Yubin Ruan:
> > On Tue, Jan 23, 2018 at 04:10:10PM +0100, Lennart Poettering wrote:
> > > On Di, 23.01.18 09:09, Reindl Harald (h.rei...@thelounge.net) wrote:
> > > > depeding on how your network is configured use "network.service" or
> > > > "networkmanager.service" (or however the networkmanager service is
> > > > called in
> > > > detail, i don#t use it)
> > >
> > > Nope. Use "network-online.target" if you are looking for a generic
> > > unit to order after that is reached only after the network has been
> > > "configured" for the first time, for some vague definition of
> > > "configured", that is up to the networking implementation to fill with
> > > sense...
> >
> > Now I have these in the configuration file
> >
> > [Unit]
> > Description=Sync mail
> > Wants=network-online.target
> > After=network.target network-online.target
> >
> > [Service]
> > Type=oneshot
> > ExecStart=/path/to/the/script
> > TimeoutStartSec=1min30s
> >
> > [Install]
> > WantedBy=default.target
> >
> > However the script is still broken at system startup. Hmm...I am using a
> > Ubuntu 16.04LTS. I will post if there are any news
>
> AGAIN: how is your network started
>
> Lennart is *not* correct - at least on Fedora all the wait-online stuff
> don't work while "After=network.service" does when you still ue the cliassic
> network.service for a lot of obvious reasons
>
> [root@srv-rhsoft:~]$ cat /etc/rc.d/init.d/network
> #! /bin/bash
> #
> # network Bring up/down networking
> #
> # chkconfig: - 10 90
> # description: Activates/Deactivates all network interfaces configured to \
> # start at boot time.
> #
> ### BEGIN INIT INFO
> # Provides: $network
> # Should-Start: iptables ip6tables NetworkManager-wait-online NetworkManager
> $network-pre
> # Short-Description: Bring up/down networking
> # Description: Bring up/down networking
> ### END INIT INFO
Below are /etc/init.d/networking and /etc/init.d/network-manager respectively.
It seems that it is /etc/init.d/networking that is responsible for bringing up
the network.
##
# /etc/init.d/networking
##
#!/bin/sh -e
### BEGIN INIT INFO
# Provides: networking ifupdown
# Required-Start:mountkernfs $local_fs urandom
# Required-Stop: $local_fs
# Default-Start: S
# Default-Stop: 0 6
# Short-Description: Raise network interfaces.
# Description: Prepare /run/network directory, ifstate file and raise
network interfaces, or take them down.
### END INIT INFO
PATH="/sbin:/bin"
RUN_DIR="/run/network"
IFSTATE="$RUN_DIR/ifstate"
STATEDIR="$RUN_DIR/state"
[ -x /sbin/ifup ] || exit 0
[ -x /sbin/ifdown ] || exit 0
. /lib/lsb/init-functions
CONFIGURE_INTERFACES=yes
EXCLUDE_INTERFACES=
VERBOSE=no
[ -f /etc/default/networking ] && . /etc/default/networking
verbose=""
[ "$VERBOSE" = yes ] && verbose=-v
process_exclusions() {
set -- $EXCLUDE_INTERFACES
exclusions=""
for d
do
exclusions="-X $d $exclusions"
done
echo $exclusions
}
process_options() {
[ -e /etc/network/options ] || return 0
log_warning_msg "/etc/network/options still exists and it will be IGNORED!
Please use /etc/sysctl.conf instead."
}
check_ifstate() {
if [ ! -d "$RUN_DIR" ] ; then
if ! mkdir -p "$RUN_DIR" ; then
log_failure_msg "can't create $RUN_DIR"
exit 1
fi
if ! chown root:netdev "$RUN_DIR" ; then
log_warning_msg "can't chown $RUN_DIR"
fi
fi
if [ ! -r "$IFSTATE" ] ; then
if ! :> "$IFSTATE" ; then
log_failure_msg "can't initialise $IFSTATE"
exit 1
fi
fi
}
check_network_file_systems() {
[ -e /proc/mounts ] || return 0
if [ -e /etc/iscsi/iscsi.initramfs ]; then
log_warning_msg "not deconfiguring network interfaces: iSCSI root is
mounted."
exit 0
fi
while read DEV MTPT FSTYPE REST; do
case $DEV in
/dev/nbd*|/dev/nd[a-z]*|/dev/etherd/e*|curlftpfs*)
log_warning_msg "not deconfiguring network interfaces: network
devices still mounted."
exit 0
;;
esac
case $FSTYPE in
nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|pvfs|pvfs2|fuse.httpfs|fuse.curlftpfs)
log_warning_msg "not deconfiguring network interfaces: network file
systems still mounted."
exit 0
;;
esac
done < /proc/mounts
}
check_network_swap() {
[ -e /proc/swaps ] || return 0
while read DEV MTPT FSTYPE REST; do
case $DEV in
/dev/nbd*|/dev/nd[a-z]*|/dev/etherd/e*)
log_warning_msg "not deconfiguring network interfaces: network swap
still mounted."
exit 0
;;
esac
done < /proc/swaps
}
ifup_hotplug () {
if [ -d /sys/class/net ]
then
ifaces=
Re: [systemd-devel] Unclear behavior of tmpfiles.d "f" type
On Mo, 15.01.18 15:34, Eli Schwartz (eschwa...@archlinux.org) wrote: > Over in Arch Linux, I am trying to move some packages over from using > post-install scripts to using tpmfiles.d/sysusers.d for any applicable > behavior. Occasionally, default files need to be created with the > contents of some specifier, for example %H. > > I don't think /usr/share/factory is appropriate for this, but it > shouldn't be overwritten with "F" type either. So "f" seems most > appropriate. > > But re-running systemd-tmpfiles repeatedly appends the argument to the > file, which doesn't seem right. I cannot offhand think of a situation > where I would want that utility, anyways. Yes, I agree. I think the current O_APPEND behaviour indeed does not make much sense, and O_EXIST would make more sense and actually be in line with what the documentation suggests. I have thus prepared a PR that fixes this and makes it work like you want: https://github.com/systemd/systemd/pull/7983 It's a change of behaviour, but i think one we can get away with as the old behaviour really didn#t make much sense and didnt match what the documentation suggested. > Also, how do I use a specifier in an argument here? Should I use "F" > mode to write a file to /usr/share/factory and then on the next line use > "C" to copy it over? That's not very simple IMHO. let's fix tmpfiles with the aforementioned PR first. And then my answer is: use "f", as you originally wanted to. Thanks for pointing this out, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Trouble with speed/mode in .link files
On Di, 02.01.18 13:32, Bruce A. Johnson (bjohn...@blueridgenetworks.com) wrote:
> I've been trying for a few days to figure out how to set Ethernet speed
> and mode using a .link file, and I can't figure out what I'm doing
> wrong. I've got a renamed interface ("eth2" -> "en01"), and ethtool
> allows me to change it with no problem, but I get "Invalid argument"
> messages from link_config, and the device ends up with the speed of the
> connected switch and half-duplex.
>
> Here's my config file:
> > # cat /etc/systemd/network/80-en01.link
> > [Match]
> > MACAddress=00:0d:b9:48:36:4a
> >
> > [Link]
> > AutoNegotiation=no
> > Duplex=full
> > BitsPerSecond=10M
> >
>
> Running udevadm to test the config gives me this:
> > # udevadm test-builtin net_setup_link /sys/class/net/en01
> > calling: test-builtin
> > === trie on-disk ===
> > tool version: 234
> > file size: 8715156 bytes
> > header size 80 bytes
> > strings 1900828 bytes
> > nodes 6814248 bytes
> > Found container virtualization none.
> > timestamp of '/etc/systemd/network' changed
> > timestamp of '/run/systemd/network' changed
> > ID_NET_DRIVER=igb
> > link_config: Cannot set device settings for en01 : Invalid argument
> > Could not set speed or duplex of en01 to 10 Mbps (full): Invalid argument
> > ID_NET_LINK_FILE=/etc/systemd/network/80-en01.link
>
> I'm running systemd version 234, built from source using OpenEmbedded.
There were some fixes in the area recently, consider upgrading to
something newer, please.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] date ranges with systemd-journal-gatewayd
On Mi, 10.01.18 16:46, Jameson Graef Rollins (jroll...@finestructure.net) wrote: > Hello. Is it possible to specify date ranges with > systemd-journal-gatewayd (i.e. equivalent of --since= and --until= in > journalctl)? I see there is a "Range:" header option that allows > restricting entries by "cursor", but I can't figure out how to translate > dates into that interface. Cursors won't help you to filter by date. Filtering by date is not available currently in systemd-journal-gatewayd. But adding this does make sense. Please file a github RFE issue about this. Or even better, post a github PR that adds this! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how is systemd-journal-gatewayd filtering logs?
On Mi, 10.01.18 19:03, Jameson Graef Rollins (jroll...@finestructure.net) wrote: > Hello, I'm having another systemd-journal-gatewayd issue... > > I'm finding that journal-gatewayd is not returning all logs that are > actually available in the journal to users with appropriate privileges. > > In particular, I have a service whose managed ExecStart program is > writing to stdout and stderr, all of which are captured by journald. > Using journalctl I can see all the process output in the logs. However, > none of this output is available via journal-gatewayd. > > Why are these logs being filtered by journal-gatewayd? How can I force > it to not filter any logs from the journal? Hmm, this might be an access control issue? systemd-journal-gatewayd.service runs in the "systemd-journal" group, which should normally have access to all journal files, by means of appropriate ACL entries. Consider checking whether the ACLs are all set up properly, so that that group gets proper access. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] question about socket activation
On Fr, 29.12.17 17:19, eshark (eshar...@163.com) wrote: > Hi, All > I tried to test the socket activation by a simple foobar.socket and > foobar.service, which are as the following: > foobar.socket: >[Socket] >ListenStream=/dev/socket/foobar > > >[Install] >WantedBy=sockets.target > > > foobar.service: >[Service] >Type=simple >ExecStart=/usr/bin/test-socket > Restart=no > > > I also wrote a simple program to connect to /dev/socket/foobar , in > order to activitate the foobar.service. > When I ran the program, the foobar.service was started by systemd , and > the foobar.socket changed from 'listening' state to 'running' state. > All works OK as expected, but when I killed the test-socket, it was > started again by the systemd, even if I didn't run my program. > And from the system journal logs , I found that > " > Line 2035: 31,29604,571630004,-;systemd[1]: foobar.socket got notified about > service death (failed permanently: no) > Line 2038: 31,29605,571630065,-;systemd[1]: foobar.socket changed running -> > listening > Line 2050: 31,29609,571632385,-;systemd[1]: Incoming traffic on foobar.socket > Line 2056: 28,29611,571633087,-;systemd[1]: Cannot add dependency job for > unit systemd-bus-proxyd.socket, ignoring: Unit systemd-bus-proxyd.socket > failed to load: No such file or directory. > Line 2056: 28,29611,571633087,-;systemd[1]: Cannot add dependency job for > unit systemd-bus-proxyd.socket, ignoring: Unit systemd-bus-proxyd.socket > failed to load: No such file or directory. > Line 2065: 31,29614,571633544,-;systemd[1]: foobar.socket changed listening > -> running > " > It seems that immediately after the death of foobar.service,some unknown > incoming traffic on foobar.socket made the foobar.service started again by > the systemd . > Could anyone give me some suggestion that who connected to the > foobar.socket ? Any idea about how to debug this problem is very > appreciated. If your service is activated due to incoming traffic and you do not process the incoming traffic and exit, then you will be started immediately again, as the socket still has traffic queued. The idea is usually to process everything queued up on the listening socket, and then exit until the next incoming traffic. If you never accept any of the incoming connections you hence will make systemd busy loop around your service. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is it a bug of manager->n_on_console?
On Mo, 25.12.17 13:31, piliu (pi...@redhat.com) wrote: > Hi, > > When debugging with a shell, manager_status_printf() always prints "A > start job...". After tracing the systemd's code, I found in that > function, the cond "if (type == STATUS_TYPE_EPHEMERAL && m && > m->n_on_console > 0)" does not meet. > > With a debugging patch, I got the following message, which indicates > that there is a reference count bug with n_on_console.1 > The debugging message: > Manager:0x55e55d91d110, unit: dracut pre-pivot and cleanup hook > n_on_console++, >1 > service_set_state Manager:0x55e55d91d110, unit: dracut pre-pivot and > cleanup hook n_on_console--, >0 > Manager:0x55e55d91d110, unit: Kdump Vmcore Save Service n_on_console++, >1 > Manager:0x55e55d91d110, unit: Kdump Vmcore Save Service n_on_console--, >0 > Manager:0x55e55d91d110, unit: dracut pre-pivot and cleanup hook > n_on_console--, >-1 > Manager:0x55e55d91d110, unit: Kdump Emergency n_on_console++, >0 > Manager:0x55e55d91d110, unit: Kdump Emergency n_on_console--, >-1 > Manager:0x55e55d91d110, unit: Kdump Error Handler n_on_console++, >0 > > Where you can see "dracut pre-pivot and cleanup hook" dec the refcnt > twice. (Note: n_on_console is declared as unsigned, so here the negative > value reflects the underflow.) Thanks for tracking this down btw. For the sake of the archives, this is tracked here now: https://github.com/systemd/systemd/pull/7824 Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add filter for ActiveState property and get to know for which object this property is?
On Di, 16.01.18 16:13, Tomasz Michalski (tmichalsk...@gmail.com) wrote: > And I have other question. Generally we wonder what will be better design > for monitoring systemd services > 1.) > - add-match to ActiveState > - subscribe to systemd1.Manager > - then we have to start in separate thread some infinitive-loop with > sd_bus_wait() > and sd_bus_process() (*) > 2.) > - asking for example each 5s all services with the aid of method > sd_bus_get_property about ActiveState. None additional thread is required > in our case as timer when expires send notification to existed infinity > while loop from current handler. > > I wonder which solution occupy more processor. From the first glance it > seems like second one, because there might be too much unnecessary > communication through the bus in order to get to know about systemd service > states. > However take care that here (*) we have to have some infinity while loop > probably in separate thread which will block thread waiting for signals > from systemd. As far as timers are concerned in 2nd solution none > additional thread is required. Is it possible somehow in 1.) not to have > additional thread in order to receive signal from systemd? > Moreover 2nd solution seems to be better in case when systemd1.Manager fail > at all (will be killed). In 2nd solution we will get to know it immediately > as there will be none response on sd_bus_get_property. In 1.) solution we > won't know that, thinking services are in active state. > Thanks in advance for your opinions. This of course all matters on how much stuff actually happens on your system. I generally would suggest watching the PropertiesChanged stuff with a precise "path" match. But if you have services that change state all the time, then polling might be better. But I'd not go for that option unless oyu have hard performance data. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to know what exactly parameter set in busCtl methods?
On Di, 16.01.18 12:52, Tomasz Michalski (tmichalsk...@gmail.com) wrote: > Hi > I have a problem with call methods from terminal which take an argument, > for example when I try to use this one: > busctl call org.freedesktop.systemd1 > /org/freedesktop/systemd1/unit/syscom_2epath org.freedesktop.systemd1.Unit > Kill > I get output > Invalid arguments '' to call org.freedesktop.systemd1.Unit.Kill(), > expecting 'si'. There's TAB completion btw, that helps you with this. and "si" tells you that you need to specify a string and an integer. What the string and integer encode is usually documented here: https://www.freedesktop.org/wiki/Software/systemd/dbus/ Though that document is unfortunately a bit out of date. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add filter for ActiveState property and get to know for which object this property is?
On Di, 16.01.18 15:41, Tomasz Michalski (tmichalsk...@gmail.com) wrote:
> Handler:
> int propertiesChangedHandler(sd_bus_message *message, void *userdata,
> sd_bus_error *error)
> {
> const char *data;
> const char *path;
> int r = 0;
>
> if(!message)
> printf("Empty message provided\n");
>
> path = sd_bus_message_get_path(message);
> if (!path)
> {
> printf("Empty message provided\n");
> return 0;
> }
>
> r = sd_bus_message_read(message, "s", &data); //here problem with
> parsing ActiveState,SubState
The PropertiesChanged signal sends a more complex data struct
back. For details see the D-Bus spec:
https://dbus.freedesktop.org/doc/dbus-specification.html
It's a bit nasty to parse that out, but doable.
> Question:
> How to narrow down filter? In the above examples the handler will be
> triggered by any property change. I am only interested in ActiveState,
> eventually SubState trigger. Should I add in sd_bus_add_match:
> "arg1='ActiveState'",
> "arg2='SubState'"
> ?
Unfortunately D-bus does not allow such finegrained matches. You
cannot look inside of arrays or dicts with them.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dependencies on DBus activated services during shutdown
On Mo, 08.01.18 16:07, Michal Koutný (mkou...@suse.com) wrote: > Hello, > I'd like to ask your opinion on the following situation. > > B.service exposes its API through D-Bus. A.service uses this API and > thus it has a dependency on B.service. This is implicit though -- and > we're happy we can rely on D-Bus activation and needn't to list all > dependencies explicitly. > > As it comes, A.service needs B.service for proper termination. During > the shutdown transaction there is unspecified ordering of the two (since > the dependency is implicit only) and B.service is stopped before > A.service. If you need it for proper termination you should declare the dep really. My general recommendation would be though to write daemons in a fashion that they do not require any other daemons to shut down in an orderly fashion. It's a matter of general robustness I guess: if your daemon is written in a way that it basically can die abruptly any time without leaving unclean state around then this also means that shutting it down always works and has no dependencies. That said, I am full aware that it might not be possible to write all daemons in this fashion... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multiple services using the same core service?
On Di, 26.12.17 01:39, 林自均 (johnl...@gmail.com) wrote: > Hi folks, > > I am trying to achieve: > > # systemctl start sshd-shell.service (1) > # systemctl start sshd-sftp.service (2) > # systemctl stop sshd-shell.service (3) > # systemctl stop sshd-sftp.service (4) > > Before the command (1), sshd is not running. By typing (1), > /etc/sshd_config is configured to accept ssh shell connections but no sftp > connections, and then start sshd. By typing (2), /etc/sshd_config is > configured to accept sftp connections too, and sshd is reloaded. By typing > (3), /etc/sshd_config is configured to refuse ssh shell connection, and > sshd is reloaded again. By typing (4), sshd will be stopped. Quite frankly, this is not really in line with how systemd services are supposed to be used. They are supposed to wrap running processes, but not wrap configuration applied to others really. But anyway, of course, it's up to you how to make use of this stuff... > The current problem is that I don't know if there is a better way to > achieve this. For example, I have to sleep 1 second before reloading > sshd-core.service in sshd-shell.service because otherwise sshd didn't setup > the signal handler for SIGHUP and will terminate itself. Or systemd doesn't > suggest such use case? Yes, it's not really in-line with how this stuff was designed... That said, I am pretty sure there's something wrong with your sshd-core.service: the unit should not be considered up before the daemon process is fully running, and that includes having set up SIGHUP handlers properly. Most likely the Type= stuff is not set up correctly in that unit (or sshd is broken and doesn't set things up fully before reporting its startup being complete). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?
On Tue, 23 Jan 2018, Simon McVittie wrote: I'm not sure why the old behavior is not compatible with modern storage The traditional behaviour requires you to have a well-defined point during boot at which you know that all hardware that was attached at power-on has been detected, and all hardware that subsequently appears was hot-plugged and should go through a different code path; but with modern buses (most visibly USB, but also buses that you probably think of as more static than they really are), there is no time at which you can know that all hardware that was attached at power-on has now been detected. It would be possible to use an arbitrary timeout, but arbitrary timeouts are a problematic design: either they're too short and they unpredictably miss some initially-attached hardware, or they're too long and they arbitrarily slow down everyone's boot process, or (more likely) both failure modes at the same time for different people. Suppressing the auto mount when a device (re)appears, is usually desired during some administrative tasks. What about lowering the hurdle for administrators by introducing a new systemctl command? Maybe something like: systemctl lock $DEVICE We could write the name of $DEVICE in some directory below /run/systemd. An udev rule could parse this directory when an add event for a device occurres and if $DEVICE matches, it could set SYSTEMD_READY=0. We would only need to make sure that SYSTEMD_READY gets reset back to 1 at an: systemctl unlock $DEVICE That shouldn't be too hard to code either. Would this be an acceptable approach? Regards Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?
On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote: > Would this be an acceptable approach? Since a long time there has been a proper API for this: just take a BSD file lock on the device node and udev won't bother with the device anymore. As soon as you close the device fully (and thus also lost all locks), udev will notice and then reprobe it again. It's a bit underdocumented, but it's the right way, doesn't leave artifacts in the system around and uses the appropriate OS primitives for what it needs to do. If you need this in shell, then I figure util-linux' flock tool should be something you can make work, as it appears to be a command line wrapper around BSD file locks. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?
On Di, 23.01.18 16:54, Reindl Harald (h.rei...@thelounge.net) wrote: > > > Am 23.01.2018 um 16:49 schrieb Simon McVittie: > > On Tue, 23 Jan 2018 at 15:47:21 +0100, Franck Bui wrote: > > > Basically, systemd mounts all filesystems listed in /etc/fstab (unless > > > "noauto" is used) which is good since that's how fstab was used when > > > SysV was the init system. > > > > > > However it also introduced another "feature" which basically > > > automagically mounts a filesystem (listed in fstab) every time its > > > backend device re-appears. > > > > Am I right in thinking this is only done if the filesystem is not declared > > as noauto in fstab? > > with Fedora 27 (yesterday upgraded) systemd even don't leave "noauto" > mount-point in peace and spits the "Failed to read symlink target for > /mnt/arrakis: Permission denied" for fuse-mountpoints multiple times each > day into the systemlogs (systemd-234-9.fc27.x86_64) Yeah, FUSE is weird. It exposes mount points that root can't access. I am note sure how we could safely detect such mounts in a non-ugly way though (as statvfs() on such mounts won't work), and I am not sure we should downgrade EACCES log messages in a blanket fashion since usually they indicate MAC issues, that shouldn't be ignored... We do generate mount units for all mount points listed in /etc/fstab unconditionally. This is so that RequiresMountsFor= can work for them and such. Specifying "noauto" doesn't mean "don't generate mount units at all". It just means "don't pull them explicitly into the initial transaction". Anyway, please file a github issue, we should do something about this. (That said, this is entirely unrelated to Franck's point AFAICS) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?
On Di, 23.01.18 15:47, Franck Bui (f...@suse.de) wrote:
> Hi,
>
> I'm resurrecting an old but recurrent issue here which I'd like to
> clarify one more time.
>
> Basically, systemd mounts all filesystems listed in /etc/fstab (unless
> "noauto" is used) which is good since that's how fstab was used when
> SysV was the init system.
>
> However it also introduced another "feature" which basically
> automagically mounts a filesystem (listed in fstab) every time its
> backend device re-appears.
>
> And this part confuses a lot of users since fstab has always been used
> to list filesystems that should be mounted during the boot process
> only. It has never been the place used by disk managers to list
> mount-points that should be automatically mounted after the system
> booted.
Well, the way I understood "auto" as opposed to "noauto" was "make
sure this is mounted while the system is up"...
I think it's moot discussing which intrepretation is the more correct
there, though…
> Furthermore, it complicates the disk administrative tasks because now
> one needs to be careful when it creates and initialize partitions
> because systemd can mount the partition on the back of the user. We
> recently had one such bug report (again).
You have to be careful there anyway. If you want exclusive access to a
block device, and don't want udev (and thus ultimately systemd) take
notice while you do that then take a BSD file lock on the device (see
other mail). Note that systemd is just one consumer of udev's
notifications there, and if you want to block all of them out while
you manipulate your block device, then there's no way around taking
the BSD lock anyway...
> According to Lennart[1], this feature is there because:
>
> "mount it if it is around at boot, but not later" is not
> available, since the idea is not compatible with modern
> storage.
>
> I'm not sure why the old behavior is not compatible with modern
> storage but with the following trivial change:
>
>static bool mount_is_auto(const MountParameters *p) {
>assert(p);
>
> -return !fstab_test_option(p->options, "noauto\0");
> +return fstab_test_option(p->options, "auto\0");
>}
>
> it seems to me that it could have the best of both worlds.
Well, traditionally "auto" was a boolean (and it is in the /bin/mount
sources still): "auto" means on, "noauto" means off. And the default
was "auto". Redefining this to make something else the default, or
even treating this as a tri-state now of "on", "off",
"something-in-between" sounds like a bigger redefinition than the
change systemd made there...
> So the question is now: "what am I missing ?"
I am not convinced the reasoning is convincing for such a major change
(I mean, let's not forget that systemd's current behaviour has been
around for more than half a decade too already). If you want other
bits of the code not to interfere what you are doing, then take the
BSD lock and all will be good, it's the right, the better thing to do,
and you have to do it anway. It will not only stop systemd from
interfering but everything else too...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] date ranges with systemd-journal-gatewayd
On Wed, Jan 24 2018, Lennart Poettering wrote: > On Mi, 10.01.18 16:46, Jameson Graef Rollins (jroll...@finestructure.net) > wrote: > >> Hello. Is it possible to specify date ranges with >> systemd-journal-gatewayd (i.e. equivalent of --since= and --until= in >> journalctl)? I see there is a "Range:" header option that allows >> restricting entries by "cursor", but I can't figure out how to translate >> dates into that interface. > > Cursors won't help you to filter by date. > > Filtering by date is not available currently in > systemd-journal-gatewayd. But adding this does make sense. Please file > a github RFE issue about this. Or even better, post a github PR that > adds this! Thanks for the response, Lennart. I actually see now that an RFE has already been submitted: https://github.com/systemd/systemd/issues/4883 I'll look into making a patch. jamie. signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Side effects of `systemctl daemon-reload`?
I have cluster of 100s of nodes with systemd-232. To work-around a recently discovered bug in systemd (https://github.com/systemd/systemd/issues/7798), I want to deploy a timer to all my nodes that will check the number of units and run `systemctl daemon-reload` once a certain threshold is hit (100K for example). I am asked whether I could have the timer skip the check and blindly run `systemctl daemon-reload` at every invocation. Would there be any problem with that? IIUC, reloading the daemon is a rather "safe" operation? -- Best, Daniel smime.p7s Description: S/MIME Cryptographic Signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?
24.01.2018 17:13, Lennart Poettering пишет: > On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote: > >> Would this be an acceptable approach? > > Since a long time there has been a proper API for this: just take a > BSD file lock on the device node and udev won't bother with the > device anymore. As soon as you close the device fully (and thus also > lost all locks), udev will notice and then reprobe it again. > How exactly is udev relevant here? This discussion has nothing to do with udev. > It's a bit underdocumented, but it's the right way, doesn't leave > artifacts in the system around and uses the appropriate OS primitives > for what it needs to do. > > If you need this in shell, then I figure util-linux' flock tool should > be something you can make work, as it appears to be a command line > wrapper around BSD file locks. > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?
On Mi, 24.01.18 22:01, Andrei Borzenkov (arvidj...@gmail.com) wrote: 1;5002;0c > 24.01.2018 17:13, Lennart Poettering пишет: > > On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote: > > > >> Would this be an acceptable approach? > > > > Since a long time there has been a proper API for this: just take a > > BSD file lock on the device node and udev won't bother with the > > device anymore. As soon as you close the device fully (and thus also > > lost all locks), udev will notice and then reprobe it again. > > > > How exactly is udev relevant here? This discussion has nothing to do > with udev. systemd acts on udev's notifications. Other daemons do too. If you don't want that all those apps and services act on it for your block device, then the right approach is to block udev from doing so, i.e. go to the source, not to the symptom. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?
24.01.2018 22:08, Lennart Poettering пишет: > On Mi, 24.01.18 22:01, Andrei Borzenkov (arvidj...@gmail.com) wrote: > 1;5002;0c >> 24.01.2018 17:13, Lennart Poettering пишет: >>> On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote: >>> Would this be an acceptable approach? >>> >>> Since a long time there has been a proper API for this: just take a >>> BSD file lock on the device node and udev won't bother with the >>> device anymore. As soon as you close the device fully (and thus also >>> lost all locks), udev will notice and then reprobe it again. >>> >> >> How exactly is udev relevant here? This discussion has nothing to do >> with udev. > > systemd acts on udev's notifications. Other daemons do too. If you > don't want that all those apps and services act on it for your block > device, then the right approach is to block udev from doing so, > i.e. go to the source, not to the symptom. > You cannot lock device that does not exist. And as soon as it appears it is mounted. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Side effects of `systemctl daemon-reload`?
24.01.2018 21:33, Daniel Wang пишет: > I have cluster of 100s of nodes with systemd-232. To work-around a recently > discovered bug in systemd (https://github.com/systemd/systemd/issues/7798), > I want to deploy a timer to all my nodes that will check the number of > units and run `systemctl daemon-reload` once a certain threshold is hit > (100K for example). > > I am asked whether I could have the timer skip the check and blindly run > `systemctl daemon-reload` at every invocation. Would there be any problem > with that? IIUC, reloading the daemon is a rather "safe" operation? > There were quite some subtle issues caused by incomplete state preserved over reload. So YMMV. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?
On Mi, 24.01.18 22:12, Andrei Borzenkov (arvidj...@gmail.com) wrote: > 24.01.2018 22:08, Lennart Poettering пишет: > > On Mi, 24.01.18 22:01, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > 1;5002;0c > >> 24.01.2018 17:13, Lennart Poettering пишет: > >>> On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote: > >>> > Would this be an acceptable approach? > >>> > >>> Since a long time there has been a proper API for this: just take a > >>> BSD file lock on the device node and udev won't bother with the > >>> device anymore. As soon as you close the device fully (and thus also > >>> lost all locks), udev will notice and then reprobe it again. > >>> > >> > >> How exactly is udev relevant here? This discussion has nothing to do > >> with udev. > > > > systemd acts on udev's notifications. Other daemons do too. If you > > don't want that all those apps and services act on it for your block > > device, then the right approach is to block udev from doing so, > > i.e. go to the source, not to the symptom. > > You cannot lock device that does not exist. And as soon as it appears it > is mounted. hu? Thomas' proposed approach of "systemctl lock $DEVICE" also requires there to be a known path for a device, hence it must already be plugged in already? Also, it's not that systemd takes possession of arbitrary devices just like that. It does that because the device was listed explicitly in /etc/fstab as "auto" already, and your system wouldn't even have booted if the device didn't show up during boot. I think you have a different usecase though? Not sure I grok it though? you want to turn off all hotplug handling for all future devices entirely? what's the usecase? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Side effects of `systemctl daemon-reload`?
On Mi, 24.01.18 10:33, Daniel Wang (wonder...@google.com) wrote: > I have cluster of 100s of nodes with systemd-232. To work-around a recently > discovered bug in systemd (https://github.com/systemd/systemd/issues/7798), > I want to deploy a timer to all my nodes that will check the number of > units and run `systemctl daemon-reload` once a certain threshold is hit > (100K for example). > > I am asked whether I could have the timer skip the check and blindly run > `systemctl daemon-reload` at every invocation. Would there be any problem > with that? IIUC, reloading the daemon is a rather "safe" operation? When you have unit files that have multiple ExecXYZ= lines of the same type (such as a Type=oneshot file with three ExecStart= lines), and you change these lines between reloads then there's the conceptual problem that it's not clear where systemd shall continue execution next: the line it currently executes might have been removed or changed, and there's no clear rule how to recognize in the changed version at which line we are now, and which one to start next. Example: Consider a service: [Service] ExecStart=/usr/bin/one ExecStart=/usr/bin/two ExecStart=/usr/bin/three Now you change it to: [Service] ExecStart=/usr/bin/one ExecStart=/usr/bin/foo ExecStart=/usr/bin/qux ExecStart=/usr/bin/three And reload, while the process "two" was running. What should happen now? Should systemd now run "foo"? or maybe "quux"? Or "three"? Now, it's not just about replacing lines fully or adding and removing some, but also just slightly altering the command line arguments. Because it isn#t conceptually clear what to run next in such a case versions of systemd before 233 had the simple rule: "we start from the beginning" again, after a reload we'd always start the first of the ExecStart= again. In 233 this was improved a bit. There we'll try to find the right line to continue with by searching for it literally, and falling back to a simple index-based approach to this if we can't find it literlal. It's making the best from a bad situation, and makes things fully reliable when the unit file didn't change at least. The above is the major caveat when reloading the daemon in full: if you have unit files with multiple ExecXYZ= lines of the same type and you keep reloading systemdyou are in trouble in < 233, and on >= 233 you are still possibly in trouble if you modify them in between but are safe if you just keep them as-is. The relevant PR is https://github.com/systemd/systemd/pull/5354 Another caveat is that because all state is flushed out and then rebuild in full the operation is relatively heavy if you have tons of units. Other than the above doing reloads should be safe and not lose state. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unclear behavior of tmpfiles.d "f" type
On 01/24/2018 05:16 AM, Lennart Poettering wrote: > Yes, I agree. I think the current O_APPEND behaviour indeed does not > make much sense, and O_EXIST would make more sense and actually be > in line with what the documentation suggests. > > I have thus prepared a PR that fixes this and makes it work like you > want: > > https://github.com/systemd/systemd/pull/7983 > > It's a change of behaviour, but i think one we can get away with as > the old behaviour really didn#t make much sense and didnt match what > the documentation suggested. Thanks! -- Eli Schwartz Bug Wrangler and Trusted User ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl is-active command returns inactive even if the unit does not exist
Hi folks, "systemctl is-active" command gives "inactive" no matter the unit exists and indeed inactive or it just not exist. This behavior is semantically true since a unit can never be active if it does not exist. But "systemctl is-enabled" command will give a clear result "Failed to get unit file state for no-exist.service: No such file or directory" to indicate user the existence of the given unit. I am wondering if "systemctl is-active" should behave the same. systemctl --version systemd 235 systemctl is-active non-exist.service inactive systemctl is-enabled non-exist.service Failed to get unit file state for non-exist.service: No such file or directory Best regards, Kevin Hsu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl is-active command returns inactive even if the unit does not exist
On Thu, 25 Jan 2018, Kevin Hsu wrote: Hi folks, "systemctl is-active" command gives "inactive" no matter the unit exists and indeed inactive or it just not exist. This behavior is semantically true since a unit can never be active if it does not exist. But "systemctl is-enabled" command will give a clear result "Failed to get unit file state for no-exist.service: No such file or directory" to indicate user the existence of the given unit. I am wondering if "systemctl is-active" should behave the same. I don't think it would be possible to change what "systemctl is-active" prints out now, and I think it makes sense for it to track the ActiveState property of the unit precisely. You can get the properties of a unit using "systemctl show". For example: $ systemctl show --property LoadState,ActiveState,SubState \ does-not-exist.service LoadState=not-found ActiveState=inactive SubState=dead As you can see here, what you're interested in is the "load state" of the unit, which is somewhat orthogonal to the unit's "active state". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?
On Wed, 24 Jan 2018, Lennart Poettering wrote: You cannot lock device that does not exist. And as soon as it appears it is mounted. hu? Thomas' proposed approach of "systemctl lock $DEVICE" also requires there to be a known path for a device, hence it must already be plugged in already? Not necessarily, my aproach just reads a device name, given as parameter and writes it somewhere. The device doesn't have to exist therefore. If the device name is wrong, just nothing would happen, so this seems to be quite safe. Using the flock approach makes systemd depending on util-linux. I'm not sure whether this is ideal. Regards Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
