| systemdlete | Maybe I haven't read carefully enough about cron/crontab, but I must admit to some confusion. The @reboot feature seems to be working on Devuan, but for some reason, the @reboot command I am giving it does not seem to run every time the cron daemon is re-started: Per everything I've read so far, vixie cron (which devuan uses) runs @reboot when the cron daemon is restarted (not when the system | 02:58 |
|---|---|---|
| systemdlete | itself is rebooted). So I figured I could stop and start the cron daemon and it would cause the @reboot command to run. But from what I see, it doesn't seem to happen. | 02:58 |
| systemdlete | Also, man 5 cron does not even mention @reboot (or @daily, @hourly, etc). But users of other linux distros are saying their man pages DO mention it. | 02:58 |
| systemdlete | Is devuan using a modified vixie cron, or am I simply confused by all this? | 02:59 |
| systemdlete | as always, thanks. | 02:59 |
| systemdlete | (BTW, this is not exactly urgent or very important. It's just a point of confusion, and I'd like to get it sorted out.) | 02:59 |
| systemdlete | Or are we using a non-vixie cron on devuan? | 03:02 |
| systemdlete | uhm... well, I guess anacron would not work well with @reboot since anacron works with scripts that might run at boot | 03:03 |
| systemdlete | I conclude I am simply confused. Anacron must have something to do with this. | 03:03 |
| fsmithred | systemdlete, man 5 crontab | 03:10 |
| systemdlete | fsmithred, see above. I read that already | 03:13 |
| systemdlete | more likely, something in it that I missed | 03:13 |
| fsmithred | I see where you mentioned man 5 cron | 03:14 |
| systemdlete | typo, sorry | 03:14 |
| fsmithred | did you also read man 5 crontab? Mine talks about @reboot @weekly, etc | 03:14 |
| systemdlete | there is no man 5 cron on my system, only man 5 crontab | 03:14 |
| systemdlete | it's not in mine, no | 03:15 |
| systemdlete | and other users (on other systems) report it is not mentioned in their man page versions | 03:15 |
| systemdlete | so apparently, I am not the only one. | 03:15 |
| systemdlete | I have 3.0pl1-162 installed on my daedalus | 03:16 |
| systemdlete | maybe you have another cron installed? | 03:16 |
| systemdlete | if so, I might consider switching to yours | 03:17 |
| fsmithred | I just had to do 'apt install cron' on a laptop to be able to make a crontab. | 03:18 |
| systemdlete | what does apt policy cron say on your laptop? | 03:18 |
| fsmithred | and the man page on the excalibur laptop mentions it just like the man page on the chimaera desktop I'm using | 03:19 |
| systemdlete | (please) | 03:19 |
| fsmithred | 3.0p11-194 on the laptop | 03:19 |
| systemdlete | ok, so yours is slightly ahead of my version | 03:20 |
| fsmithred | 3.0pl1-137 | 03:20 |
| fsmithred | on desktop | 03:20 |
| fsmithred | I'm guessing it's the same in daedalus | 03:20 |
| systemdlete | my chimaera also reports 3.0pl1-137, and just like yours, its man page mentions @reboot | 03:21 |
| systemdlete | but my daedalus does not | 03:21 |
| fsmithred | yeah, I'm seeing that | 03:22 |
| systemdlete | (I hope I haven't screwed up something on my daedalus) | 03:22 |
| systemdlete | seeing what? | 03:22 |
| fsmithred | that it's not mentioned in daedalus | 03:23 |
| systemdlete | thank you fsmithred. So I am not totally out of my mind. (Partially, perhaps) | 03:23 |
| fsmithred | I'm pretty sure it was someone other than you who screwed up | 03:23 |
| systemdlete | even better for me then!!! | 03:24 |
| systemdlete | lol | 03:24 |
| fsmithred | or maybe they removed because as you noted, it's not true in daedalus | 03:24 |
| systemdlete | removed that one feature (@reboot, etc) | 03:24 |
| systemdlete | ? | 03:24 |
| fsmithred | I was about to test it | 03:24 |
| fsmithred | removed or broke, I don't know | 03:24 |
| systemdlete | Just an aside, I note that the AUTHOR section of the man page, even on daedalus, indicates Paul Vixie, so something weird has happened. | 03:26 |
| rustyaxe | i see it in mine on daedalus | 03:29 |
| rustyaxe | ii cron 3.0pl1-194 amd64 process scheduling daemon | 03:29 |
| rustyaxe | /usr/share/man/man5/crontab.5.gz | 03:29 |
| systemdlete | please define "it" rustyaxe -- there are several pieces here | 03:29 |
| rustyaxe | The whole lot of it. @reboot support, man 5 crontab describing it, etc | 03:30 |
| systemdlete | and you are certain you are running daedalus? | 03:30 |
| systemdlete | did you build the package yourself? or from the repos? | 03:30 |
| fsmithred | that's the excalibur version (-194) | 03:30 |
| systemdlete | fsmithred and I are seeing something different than you | 03:31 |
| fsmithred | daedalus has -162 | 03:31 |
| systemdlete | ah, right. thanks fsmithred. | 03:31 |
| rustyaxe | https://pkginfo.devuan.org/cgi-bin/package-query.html?c=package&q=cron=3.0pl1-162 | 03:31 |
| systemdlete | rustyaxe, thanks. But we already figured out that both chimaera and excalibur have the expected man page | 03:31 |
| rustyaxe | Pretty sure it worked on daedalus before upgrading | 03:32 |
| systemdlete | it's just daedalus that seems to be different, for some reason | 03:32 |
| fsmithred | @reboot isn't working for me on excalibur right now | 03:32 |
| systemdlete | rustyaxe, yes, it seems to work here also. But the man page leads to confusion because it does not mention the vixie extensions @reboot etc | 03:32 |
| fsmithred | unless I'm doing it wrong | 03:32 |
| systemdlete | oh? | 03:32 |
| systemdlete | I don't have an excalibur here so I can't test it. | 03:33 |
| systemdlete | (though I could certainly install one, which might help the testing efforts) | 03:33 |
| fsmithred | @reboot echo 'test' >> /home/fsr/crontab.log | 03:35 |
| fsmithred | restart cron and I get nothing | 03:35 |
| systemdlete | ok | 03:36 |
| systemdlete | fsmithred, thank you for confirming all of this for me. | 03:36 |
| systemdlete | while it doesn't correct the problem, at least I don't feel like I made some huge installation/configuration error | 03:37 |
| fsmithred | I also tried rebooting the laptop. nothing. | 03:37 |
| systemdlete | well, from what I've read, it is when the cron daemon is restarted, not the system, that @reboot is run | 03:37 |
| fsmithred | yeah, I tried restarting cron several times. Tried creating the log file first so it already was there. Tried restarting anacron. | 03:38 |
| systemdlete | try stopping and restarting explicitly rather than "restart"? | 03:38 |
| systemdlete | should not make a difference I know | 03:38 |
| systemdlete | but just for science... | 03:38 |
| fsmithred | doesn't work for me on chimaera either | 03:40 |
| systemdlete | huh. I don't think I tried it there | 03:40 |
| fsmithred | I must be doing it wrong | 03:40 |
| systemdlete | not nec | 03:40 |
| systemdlete | maybe they tore out some of the support for the feature in one release, then tore out the docs for it in the next release. | 03:41 |
| systemdlete | idk, I'm just guessing | 03:41 |
| * systemdlete goes off to try the experiment on their copy of chimaera also... | 03:42 | |
| systemdlete | bbs | 03:42 |
| systemdlete | so it failed for me with chimaera also. | 03:43 |
| yeti | Don't run reboot jobs when restarting the cron daemon. | 03:44 |
| yeti | is in a debian patch | 03:44 |
| yeti | check the debsrc | 03:44 |
| systemdlete | and, like yours, it has the doc on the feature | 03:45 |
| systemdlete | yeti: what do you mean "don't" run reboot jobs? | 03:45 |
| systemdlete | could it damage the system? | 03:45 |
| yeti | thats a comment in a patch debian added to cron | 03:45 |
| systemdlete | oh | 03:46 |
| systemdlete | maybe quote stuff like that | 03:46 |
| systemdlete | I understand now, yeti | 03:46 |
| yeti | andit makes sense to run @reboot stuff only on system reboots instead of every cron restart | 03:46 |
| systemdlete | it does, indeed, but how does the cron daemon know that the system has just rebooted? | 03:47 |
| yeti | a flag file somewhere | 03:47 |
| yeti | # define REBOOT_FILE "/run/crond.reboot" | 03:51 |
| fsmithred | maybe there should be @reboot and @restart | 03:51 |
| systemdlete | ok, that seals it then. | 03:51 |
| systemdlete | maybe. | 03:52 |
| systemdlete | a more urgent solution would be to update the man page... | 03:52 |
| yeti | get the debsrc, read the diffs, one is that mentioned patch | 03:52 |
| yeti | I just hope the bsds add that too | 03:53 |
| yeti | I always took that for granted | 03:53 |
| systemdlete | not sure I want to step into that role | 03:53 |
| systemdlete | fsmithred, yeti, rustyaxe thanks to all for your help | 04:33 |
| chomwitt | in a fresh installation of daedalus netinstall with what command would i test for access to interent if ping wont work (that is the case in a qemu image running with usermode network backend). | 19:37 |
| chomwitt | curl for example is not installed | 19:37 |
| n4dir | apt-get update? | 19:39 |
| fsmithred | :) | 19:39 |
| chomwitt | ok | 19:40 |
| gnarface | you could try "traceroute -T [ip]" | 19:40 |
| chomwitt | since curl was in my mind why not apt-get | 19:40 |
| chomwitt | gnarface: checking | 19:41 |
| gnarface | though i thought you could still ping the usermode network gateway, just not pass pings through it, am i remembering that wrong? | 19:41 |
| gnarface | also, you have to remember to still assign the usermode network's gateway ip as the default gateway in the guest OS | 19:43 |
| gnarface | i don't think that part happens automatically, nor does the guest OS get a IP address by default | 19:43 |
| gnarface | or DNS servers for that matter | 19:43 |
| chomwitt | i get a big list of * * * . | 19:43 |
| gnarface | though a DNS server should be provided with the default usermode networking setup, it's just not assigned to anything in the guest OS by default | 19:44 |
| chomwitt | yes i can ping 10.0.2.2 (the qemu guest side gateway) | 19:44 |
| gnarface | alright, that's a good start at least | 19:44 |
| fsmithred | traceroute devuan.org works here in qemu | 19:45 |
| fsmithred | no network options in the command to launch the iso | 19:46 |
| fsmithred | ping failed | 19:47 |
| chomwitt | tracerout devuan.org work ok when my qemu machine (in user backend mode) has access to the interent (i found that i can fix the internet access with adding 8.8.8.8 to resolv.conf) . So i think traceroute serves me ok . | 19:48 |
| gnarface | usermode networking should define a local DNS server at 10.0.2.3 for you | 19:49 |
| gnarface | by default | 19:49 |
| gnarface | one up from the gateway | 19:50 |
| chomwitt | gnarface: i see that in the docs . but i have no idea how to use it. | 19:50 |
| gnarface | same way | 19:50 |
| gnarface | add 10.0.2.3 to your resolv.conf instead of google's | 19:50 |
| gnarface | or along side it, if you feel like | 19:51 |
| * chomwitt trying gnarface tip... | 19:51 | |
| chomwitt | doesnt work | 19:52 |
| gnarface | huh, weird... working fine here | 19:52 |
| chomwitt | testing now with tracerout devuan.org | 19:52 |
| chomwitt | nop. when i set 8.8.8.8 and save it , it work ok | 19:54 |
| gnarface | odd, but whatever works | 19:54 |
| * chomwitt thanks all for tracerout -T and tracerout devuan.org tips. | 19:56 | |
| fsmithred | yw | 19:56 |
| chomwitt | i forgot to mention that by default resolv.conf has 10.0.2.3 !! | 19:59 |
| gnarface | you using network-manager? | 19:59 |
| gnarface | or maybe DHCP? | 19:59 |
| chomwitt | gnarface: right question! i have xfce . one moment | 20:00 |
| fsmithred | yeah, n-m is the default | 20:00 |
| chomwitt | usually i test with a minimal installation with light windom managers only... anyway. n-m is the one that at each reboots sets the resolv.conf overwriting my changes? | 20:02 |
| gnarface | probably | 20:02 |
| gnarface | it's known for that, though it's not the only thing that does it | 20:02 |
| chomwitt | gnarface: in your test of 10.0.2.3 do you have n-m ? | 20:03 |
| gnarface | no, my setup's all static | 20:03 |
| gnarface | also, the guest is actually chimaera | 20:04 |
| chomwitt | ok. | 20:04 |
| chomwitt | i will try a more light qemu image with static ip. | 20:04 |
| fsmithred | I use n-m on laptop and I usually make resolv.conf immutable, but it's also possible to set the dns inside n-m | 20:05 |
| chomwitt | fsmithred: checking | 20:05 |
| fsmithred | not sure if you need to set static ip for that or not | 20:05 |
| fsmithred | my very first post to the debian forum was about network manager fighting with /etc/network/interfaces. I'd get a "not connected" icon when I was connected and vice versa. | 20:06 |
| chomwitt | i tried to set a static ip from within n-m with no luck. my virtual nic got the static ip and resolf.conf 10.0.2.3 (dns) but no internet. (traceroute test) | 20:11 |
| chomwitt | strangely after reboot n-m created another dynamic interfaca and used that! | 20:11 |
| fsmithred | and does it work now? | 20:16 |
| fsmithred | other way to set it is in /etc/dhcp/dhclient.conf | 20:17 |
| fsmithred | prepend domain-name-servers | 20:18 |
| chomwitt | just checked in an daedalus install with no gui installed and name resolution (tracerout devuan.org) wont work but tracerout -T 8.8.8.8 seems to work | 20:19 |
| chomwitt | and as i see , by default ? , /etc/network/interfaces sets eth0 to dhcp | 20:21 |
| chomwitt | fsmithred: not . in my xfce setup it wont work after reboot. its create and uses a dhcp interace. | 20:22 |
| chomwitt | but it seems that static or not doesnt matter. its a dns issue | 20:23 |
| chomwitt | indeed in my daedalus with no gui image i set a static ip and i still get no dns | 20:33 |
| chomwitt | but thanks to tracerout i think i can see that using IPs gets through | 20:33 |
| * chomwitt away for a while | 20:33 | |
| |cos| | My devuan machine still refuses to boot, without many, many attempts. | 22:00 |
| |cos| | I did PXE-boot it in order to create the supposedly missing nodes in /dev as suggested by fsmithred, but it turned out they were already there. | 22:01 |
| |cos| | It's the good old hang at "Waiting for /dev to be fully populated" that is happening. | 22:06 |
| |cos| | Adding "failsafe" as a kernel argument as suggested på rwp doesn't work this time, so I guess luck was unrelated to that on my last reboot. | 22:07 |
| |cos| | yey! it finally booted. no special tricks. i did switch from 6.1.0-32 to 6.1.0-31, but unless it is the actual switch of kernel version rather than the version in itself that ought to not be it since -31 was the failing one last time. | 22:12 |
| |cos| | Now when boot was successful, the syslog shows the system to be stuck for 47 seconds between reporting bluetooth devices and "Asymmetric key parser 'pkcs8' registered" | 22:17 |
| |cos| | i wonder if that just means it almost took me a minute to enter the passphrase for the root filesystem? maybe so. | 22:20 |
| gnarface | |cos|: classic symptoms of failing hardware | 22:24 |
| gnarface | what device it actually seems to be hanging on though, could be a red herring; often it's the power supply causing devices to not power up on time | 22:25 |
| gnarface | a failing or just insufficient wattage power supply can cause any device to hang on boot, but also this is often caused by failing mechanical harddrives | 22:28 |
| gnarface | ...or optical drives | 22:28 |
| gnarface | either could also explain why retrying it works, because if you're just barely over the margin the behavior can be intermittent | 22:29 |
| gnarface | also, either way you can usually figure it out by turning stuff off | 22:31 |
| gnarface | unplug an unnecessary device or two, deductively narrow down whether it's a particular device or just any amount of wattage worth of them | 22:31 |
| gnarface | oh, and in theory the wall power can be suspect too, if you don't have a UPS | 22:32 |
| |cos| | gnarface: you keep suggesting this… i highly doubt it's hardware given that software is involved, and it consistently happen once enough of the system is brought up that it's way past hardware initialization. | 23:44 |
| |cos| | had it happened in the first couple of seconds, sure. but this happens when more than a minute has passed on the kernel timer. | 23:45 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!